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Prefacio 


O ano era 2001 e eu estava prestes a abandonar a carreira de gerente de projetos de 
software. Eu não aguentava mais aquilo. Era o escopo que sempre mudava. O prazo 
e custo que sempre estouravam. O cliente que nunca sabia o que queria. A correria 
de fim de projeto. Fins de semana e madrugadas trabalhando. Conflitos. Prejuízo. E 
a eterna esperança de que “no próximo seria diferente”. Não dava mais. 

Naquele mesmo ano um amigo me emprestou um livro sobre uma tal FDD 
(Feature-Driven Development) e, após ler e ver sentido em muito do que estava ali, 
decidi me dar mais uma chance e tentar novamente, mas agora de uma forma dife- 
rente, afinal, pensei, se você não pode mudar uma situação, deve mudar sua atitude 
em relação a ela. Naquele momento, abrindo minha mente às possibilidades, abra- 
cei Agile - sem saber que aquilo era Agile - e mudei completamente o meu destino 
profissional. Depois do primeiro projeto conseguindo ter minha qualidade de vida 
e auto-estima profissional recuperadas, e vendo o sorriso no rosto do cliente, decidi 
mergulhar de cabeça neste mundo. Não haveria volta. 

Hoje, depois do que vi na prática, nas trincheiras, por todos esses anos, eu afirmo 
a você: o resultado dos projetos de desenvolvimento de software que utilizam méto- 
dos ágeis é muito superior se comparado às técnicas mais tradicionais de gestão de 
projetos e engenharia de software. E quando eu falo em melhor resultado, não es- 
tou falando apenas de uma maior entrega de valor, tópico brilhantemente abordado 
neste livro, mas falo também de aspectos que vão desde a geração de produtos com 
qualidade técnica à construção de um melhor ambiente de trabalho. Estou certo de 
que em poucos anos nos lembraremos de Agile como um marco na nossa profissão, 
um marco para a área de tecnologia. 

Mas, afinal de contas, o que é Agile? É uma metodologia? Um processo? Um 
conjunto de valores? Um manifesto? Ferramentas? Práticas? Um movimento? Bem, 
por incrível que pareça, esta é uma pergunta difícil de ser respondida. Uma das 
razões é porque Agile pode não ser nada do que citei, e, ao mesmo tempo, pode 
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compreender tudo aquilo. É muito difícil explicar Agile sem mostrar a prática. De 
fato, frequentemente cito que a forma correta de explicar o que é Agile deveria ser 
“Ei, venha aqui ver como estou fazendo!” E é neste ponto que destaco o valor de 
cada uma das páginas deste livro, elas mostram o Agile do “mundo real’, infestado 
de pragmatismo e de preciosas anotações de quem valoriza sim uma boa teoria, mão 
não antes de pratica-la, de vê-la realmente funcionando. 

Um livro de verdade sobre Agile não poderia ter capítulos cujos títulos fossem 
puramente relacionados a uma regra, artefato ou ferramenta de um ou outro método 
ágil. Um verdadeiro livro sobre Agile deveria manter o foco de seus capítulos na en- 
trega de valor ao negócio, na otimização deste valor e na construção de um novo 
ambiente de trabalho, uma nova gestão. Um verdadeiro livro de Agile tiraria os ho- 
lofotes dos famosos métodos ágeis, tais como Scrum, XP e Kanban, e os apresentaria 
apenas como um meio para se desenvolver da forma certa produtos que realmente 
agreguem valor a quem paga a conta: nossos clientes. 

Sendo assim, não exito em afirmar que este é um verdadeiro livro de Agile. É o 
livro que você deve ler caso queira construir um novo e melhor caminho para a sua 
carreira na área de projetos de software. 

Alexandre Magno 

Agile Expert e Fundador da Adapt Works 
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CAPITULO 1 


Introdução à Métodos Ágeis 


Na semana passada, entrevistei Joana, uma moça que havia passado 8 meses tra- 
balhando em um projeto para um grande banco. Ela e sua equipe passaram todo 
esse tempo apenas fazendo levantamento de requisitos e documentando suas des- 
cobertas, até que descobriram que o problema que o software a ser desenvolvido se 
propunha a resolver já havia sido solucionado por uma ferramenta trazida de uma 
fusão com outro banco (há dois anos atrás) e já não era mais um problema. O projeto 
foi cancelado. 

O resultado de 8 meses de trabalho de uma equipe, mais o investimento do tempo 
de diversos interessados que colaboraram com informações para o projeto se resu- 
miu a um “bolo de documentação” que agora, provavelmente, nunca mais será se- 
quer lida por ninguém. Joana estava frustrada com sua última experiência, e prova- 
velmente quem quer que estivesse pagando por esse projeto também. 

A experiência de Joana não é um caso isolado. Na verdade, muitos e muitos 
projetos tiveram e, infelizmente, ainda terão destinos semelhantes a esse. Mas por 
quê? Será que há uma forma melhor de gerenciar e desenvolver software que evite 
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tanto desperdício? A boa notícia é que há! Métodos ágeis são uma vacina contra o 
desperdício. 

Por isso, nos últimos anos, os métodos ágeis vêm ganhando mais e mais popula- 
ridade, e grandes empresas como Google, Yahoo!, Microsoft, IBM, Cisco, Symantec 
e Siemens os têm utilizado [66]. Mas afinal o que os métodos ágeis trazem de dife- 
rente? O que tem despertado tanto interesse nesses grandes players do mercado de 
tecnologia? Para compreender melhor, vejamos como tudo começou. 

No início da década de 90, no intuito de desburocratizar os processos de de- 
senvolvimento de software, novas abordagens chamadas de “processos leves”, como 
Scrum, Extreme Programming (XP), e Feature Driven Development (FDD), para 
citar algumas, começaram a emergir, mostrando-se mais bem sucedidas do que ten- 


tativas anteriores. 


1.1 O MANIFESTO ÁGIL 


Devido ao grande número de referências a esses processos leves, que emergiam como 
resposta aos constantes fracassos de projetos utilizando abordagens tradicionais, em 
fevereiro de 2001 um grupo de profissionais extraordinários do desenvolvimento de 
software reuniu-se em um Resort de Ski em Wasatch Range para discutir melhores 
maneiras de desenvolver software. Esse encontro deu origem ao manifesto ágil, uma 
declaração com os princípios que regem o desenvolvimento ágil [64]: 
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O MANIFESTO ÁGIL 


Estamos descobrindo maneiras melhores de desenvolver software, 
fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse tra- 
balho, passamos a valorizar: 


e Indivíduos e a interação entre eles mais que processos e ferra- 
mentas; 


* Software em funcionamento mais que documentação abrangente; 
* Colaboração com o cliente mais que negociação contratual; 


e Responder a mudanças mais que seguir um plano. 


Mesmo havendo valor nos itens à direita, valorizamos mais os itens à 
esquerda. 











Além desses 4 valores, o manifesto ágil também é composto por 12 princípios: 


e Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adi- 
antada de software com valor agregado. 


e Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvol- 
vimento. Processos ágeis tiram vantagem das mudanças visando vantagem 
competitiva para o cliente. 


* Entregar frequentemente software funcionando, de poucas semanas a poucos 
meses, com preferência à menor escala de tempo. 


e Pessoas de negócio e desenvolvedores devem trabalhar diariamente em con- 
junto por todo o projeto. 


e Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e 
o suporte necessário e confie neles para fazer o trabalho. 


e O método mais eficiente e eficaz de transmitir informações para e entre uma 
equipe de desenvolvimento é através de conversa face a face. 


e Software funcionando é a medida primária de progresso. 
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e Os processos ágeis promovem desenvolvimento sustentável. Os patrocinado- 
res, desenvolvedores e usuários devem ser capazes de manter um ritmo cons- 
tante indefinidamente. 


e Contínua atenção à excelência técnica e bom design aumenta a agilidade. 


* Simplicidade - a arte de maximizar a quantidade de trabalho não realizado - é 
essencial. 


e As melhores arquiteturas, requisitos e designs emergem de equipes auto- 
organizáveis. 


e Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e 
então refina e ajusta seu comportamento de acordo. 


Os profissionais que deram origem ao manifesto ágil foram Kent Beck, Mike Be- 
edle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, 
James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Ma- 
rick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland e Dave Thomas. 

Ao longo desse livro nós estudaremos como esses valores e princípio são coloca- 
dos em prática nas atividades e no dia-a-dia das equipes ágeis. 


1.2 MÉTODOS ÁGEIS 


O Manifesto ágil é o embasamento filosófico de todos os métodos ágeis e diversos 
métodos de desenvolvimento de software estão alinhados a ele. A maioria deles se 
utiliza de ciclos curtos, que são chamados de iterações e normalmente têm duração 
de poucas semanas, dessa forma garantindo feedback frequente e respostas rápidas 
às mudanças. 

Cada iteração contém todas as etapas necessárias para que se realize um incre- 
mento no produto, ou seja, no software: planejamento, análise, design, codificação, 
testes e documentação. Em métodos não ágeis, também conhecidos como métodos 
tradicionais, geralmente se encontra um processo em cascata em que todas as eta- 
pas citadas são executadas uma única vez e em sequência (ainda que idealmente, 
prevendo-se revisões incrementais de cada etapa, se necessário). 

Scrum, Extreme Programming (XP), Crystal Clear e Feature Driven Develop- 
ment são exemplos de métodos ágeis. Cada um deles traz uma abordagem diferente 
que inclui diversos valores, práticas e reuniões. O Scrum, por exemplo, traz uma 
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abordagem mais voltada para a gestão, com maior foco nas reuniões, no planeja- 
mento e na melhoria contínua. Já o XP, trazem maior enfoque nas práticas técnicas. 
Ao decorrer do livro estudaremos melhor esses métodos e exploraremos algumas 
práticas ágeis. 


A Cascata dos Métodos Tradicionais 


cc 


ão é o mais forte que sobrevive, nem o mais inteligente, mas o que melhor se 


adapta às mudanças? 
— Charles Darwin 


Em contra partida, os processos tradicionais ou em cascata (figura 1.1), que eram 
amplamente utilizados do mercado antes dos métodos ágeis, assumem que o desen- 
volvimento de software pode ser realizado através de uma sequência de atividades 
facilmente identificadas, previsíveis e repetíveis, mas diferente de outras engenha- 
rias, desenvolvimento de software requer criatividade, e geralmente envolve um alto 
nível de riscos e incertezas [38]. 

O processo cascata costuma ser realizado através de fases de análise de requisitos, 
projeto (design), implementação, testes, integração e manutenção, de forma que uma 
fase é iniciada somente quando a anterior termina. O termo foi originado em um 
artigo publicado em 1970 por W. W. Royce [52]. O próprio autor descreveu o método 
como arriscado e propenso a falhas. 


12. Métodos Ágeis Casa do Código 


Requisitos | 
wO 
tC oesi j- 
E codificação — 
El testes j- 
E ( implantação | 
E! manutenção | 


Figura 1.1: Processo em Cascata (Waterfall) 





É claro que desenvolvimento ágil não é a única forma de se encarar o desenvol- 
vimento de software, nem é a única maneira eficiente; como disse, Frederick Brooks 
em 1986, nenhuma tecnologia ou técnica de gestão resolve todos os problemas de 
todos os contextos. Ele resumiu essa ideia dizendo que “não há prata de bala” [15]. 

Métodos ágeis assumem imprevisibilidade natural do desenvolvimento de soft- 
ware, por isso, considera-se que o cliente também está aprendendo sobre o que 
precisa e, que a cada feedback pode mudar de ideia e alterar o escopo do projeto. 
Assume-se também que estimativas de esforço e tempo de desenvolvimento são, de 
fato, estimativas, e não devem ser tratadas como algo certo e sem margem de erro. 

Por assumir a imprevisibilidade envolvida no desenvolvimento de software, mé- 
todos ágeis se baseiam nos ciclos de feedback constante permitindo que o cliente e a 
equipe de desenvolvimento possam adaptar-se às mudanças, aumentando assim as 
chances de sucesso do projeto. 

Um fato interessante, que muitas vezes é deixado de lado nas discussões sobre 
métodos ágeis, é que o manifesto ágil não foi uma reação apenas aos métodos tradi- 
cionais e burocráticos, mas também foi uma reação aos métodos caóticos que resul- 
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tavam em produtos de baixa qualidade. Os métodos ágeis representam, justamente, 
um meio termo entre métodos estruturados demais e métodos sem estrutura, são o 
meio termo entre a ordem e o caos [8]. 

Com intuito de promover os métodos ágeis, foi instituída a Aliança Ágil (Agile 
Alliance), que apoiou e realizou uma série de eventos e conferências ao redor do 
mundo. Com o tempo, mais e mais empresas e pessoas foram adotando métodos 
ágeis e atualmente milhões de pessoas consideram-se praticantes desses métodos. 


Métodos Prescritivos e Adaptativos 


Métodos ágeis são adaptativos ao invés de prescritivos, por isso, incentivam a 
melhoria contínua (implicando em um constante estado de mudanças e transfor- 
mação, visando alcançar um estado melhor) através de ciclos inspeção e adaptação. 
Esse é o motivo pelo qual métodos ágeis utilizam processos empíricos, em vez de 
prescritivos [36]. 

Enquanto processos empíricos são apropriados para dominios instáveis e com 
alto nível de mudanças, processos prescritivos são indicados para atividades orde- 
nadas que podem ser alcanças através de uma sequência de passos. 


+ Prescritivo 


DO 
Oo... 


RUP XP Scrum Kanban 
(120) (13) (9) (3/5) 


+ Adaptativo 


Figura 1.2: Métodos Mais e Menos Prescritivos 


É por isso que métodos ágeis são menos explícitos em termos de papéis, ativida- 
des e artefatos do que métodos tradicionais (prescritivos). Para se ter uma ideia, o 
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RUP possui mais de 120 prescrições, o XP 13, o Scrum 9, e Kanban apenas 3 [34]. 

Quanto mais prescritivo um método for, mais específico para um determinado 
tipo de contexto ele será. Em contrapartida, quanto mais adaptativo, maior será sua 
aderência e flexibilidade para que seja otimizado com maior eficiência em diferentes 
contextos. 

Em regra geral, ao utilizar um método prescritivo como RUP, por exemplo, você, 
possivelmente, precisará encontrará muito mais do que realmente precisa, e já com 
métodos menos prescritivos como Scrum, você precisará incluir tudo aquilo que 
estiver faltando para que o processo seja eficiente em seu contexto. 


1.3 COMPREENDENDO OS VALORES ÁGEIS 


Conforme citado anteriormente, o Manifesto Ágil é formado por quatro valores fun- 
damentais, que agora vamos explorar em mais detalhes. 

O primeiro valor, que diz “indivíduos e a interação entre eles mais que proces- 
sos e ferramentas”, trata de entender que uma equipe é formada por pessoas e, que 
cada uma é diferente e única e possui pontos fortes e fracos, e não são vistas apenas 
“recursos” homogêneos e substituíveis. 

O bom relacionamento entre os membros da equipe é considerado crucial, e por 
isso, a agilidade do ambiente estimula o trabalho em equipe, a colaboração, e a comu- 
nicação constante. As equipes, geralmente, são formadas por pessoas com diferentes 
papéis, que se responsabilizam juntas pelo resultado do trabalho que realizam. 

Processos são realizados por pessoas, e as ferramentas são utilizadas por pessoas. 
Se a interação entre elas não estiver fluída e bem equilibrada, provavelmente, a eficá- 
cia dos processos e ferramentas será comprometida. Por isso, nos métodos ágeis, as 
pessoas estão em primeiro lugar. Outro fator importante é que excelentes ferramen- 
tas e processos sem pessoas excelentes envolvidas, muito provavelmente, produzirão 
um resultado medíocre em vez de excelente [19]. 

Por outro lado, é importante ressaltar que as ferramentas também são impor- 
tantes, apenas não são mais importantes do que as pessoas. Essa lógica vale para 
todos os valores do manifesto: o elemento da esquerda é mais importante do que o 
da direita, porém o da direita também é importante e relevante. 

O segundo valor “software em funcionamento mais que documentação abran- 
gente” é uma resposta a projetos tradicionais em que, por serem realizados por fases, 
costumava-se passar meses produzindo apenas documentação, que por si só, não 
agrega muito valor, ou, talvez nenhum valor ao cliente. 
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A natureza iterativa dos métodos ágeis permite que software em funcionamento 
seja entregue ao cliente em curtos períodos de tempo, dessa forma agregando va- 
lor maior em curto espaço de tempo. É claro que uma vez que a documentação é 
importante para o projeto, a cada entrega, ela poderá ser devidamente produzida e 
entregue junto com o software em funcionamento. 

A “colaboração com o cliente é mais valorizada do que negociação contratual” 
justifica-se porque o objetivo da equipe ágil é entregar um produto que agregue valor, 
e para isso é preciso estar sempre pronto a adaptar-se às mudanças que, geralmente, 
ocorrem no mundo dos negócios, e consequentemente afetam uma ideia de escopo 
inicial que o cliente tinha do projeto a ser desenvolvido. 

Contratos, geralmente, são necessários, mas muitos são protecionistas demais 
e procuram fechar o escopo do projeto desde o início, reduzindo assim as oportu- 
nidades de colaboração e descoberta junto com o cliente ao longo do processo de 
desenvolvimento, resultando em produtos que, muitas vezes, não atendem à neces- 
sidade de quem está pagando. 

O importante é que o contrato mantenha o máximo de opções abertas para que o 
projeto possa mudar na medida do necessário e dessa forma o projeto seja adaptável 
e, realmente, gere valor ao cliente. 

Além disso, é essencial a colaboração e participação do cliente durante o desen- 
volvimento. Métodos ágeis procuram trazer o cliente para perto da equipe, o cliente 
faz parte do projeto e tem um papel muito importante para que o projeto seja bem- 
sucedido. 


A única coisa constante é a mudança” 
— Heráclito de Éfeso 


Finalmente, “responder a mudanças é mais importante do que seguir um 
plano”, diz respeito, essencialmente, à capacidade de adaptação que uma equipe ágil 
precisa possuir. Planejar é preciso, mas planos não precisam ser “escritos em pedras”, 
eles podem ser apagados, corrigidos, refeitos. 

A capacidade de adaptar-se em um mundo em constante mudança é uma quali- 
dade essencial entregar projetos relevantes e bem-sucedidos. 


1.4 BENEFÍCIOS DOS MÉTODOS ÁGEIS 


Uma das maiores motivações para a transição para métodos são os benefícios que 
são trazidos para a organização devido ao valor que é agregado ao cliente com qua- 
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lidade e velocidade [63]. Métodos ágeis ajudam organizações a responder mais rapi- 
damente às necessidades do mercado, muitas vezes, resultando em grande vantagem 
competitiva. 

Uma pesquisa realizada pela VersionOne.com em 2011 [65] envolveu mais de 
6.000 pessoas e organizações dos mais variados perfis na industria de desenvolvi- 
mento de software. Ela nos mostra alguns dos principais benefícios obtidos por essas 
organizações após a transição par métodos ágeis. Os principais benefícios são: 


e Melhor Time-to-market e Maior Retorno sobre o Investimento: Quanto 
mais cedo os clientes puderem começar a utilizar o produto, mais rápido rece- 
berá o retorno do valor investido no desenvolvimento do produto, seja através 
de lucros diretos gerados pelo produto ou através dos benefícios gerados pela 
utilização do produto na organização. 


e Maior Satisfação do Cliente e Melhor Gestão de Mudanças de Prioridades: 
O planejamento iterativo permite que o cliente facilmente mude suas prio- 
ridades com impacto reduzido na produtividade da equipe porque planeja- 
se detalhamento apenas daquilo que está mais próximo de ser feito, evitando 
também desperdícios e custos desnecessários. A comunicação constante e a 
proximidade com o cliente frequentemente resulta também em um melhor 
alinhamento entre os objetivos de TI e com os objetivos de negócio da orga- 
nização. 


e Melhor Visibilidade dos Projetos: Faz parte da cultura ágil manter as in- 
formações do projeto visíveis e transparentes através de ferramentas como 
burndown-charts, e card walls (discutidas posteriormente), com as quais a 
equipe e gestão podem acompanhar dia a dia a evolução do projeto em rela- 
ção às metas do projeto e das iterações; 


e Maior Produtividade: Infelizmente, não há uma forma universalmente aceita 
de se medir produtividade de equipes de desenvolvimento de software. Mui- 
tos consideram essa tarefa até impossível ou algo subjetivo demais, mas na 
pesquisa supracitada, 75% dos participantes afirmaram ter alcançado melhor 
produtividade depois da transição para métodos ágeis; 


* Equipes mais Motivadas: Métodos ágeis promovem ritmos sustentáveis de 
trabalho, são muitos os casos em que organizações reportaram uma diminui- 
ção significativa nas horas extras e madrugadas trabalhadas depois da transi- 
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ção para métodos ágeis [20]. A promoção do ritmo sustentável, de uma cul- 
tura de qualidade, de constante comunicação e trabalho em equipe são alguns 
dos fatores que contribuem para equipes mais motivadas e satisfeitas com seu 
ambiente de trabalho. 


e Melhor Disciplina na Engenharia e Melhor Qualidade Interna: A utiliza- 
ção de práticas ágeis como redução de dívida técnica (melhorar a qualidade 
interna do produto), refactoring, desenvolvimento orientado a testes e progra- 
mação em par, unido ao mindset de qualidade estimulado de pelos métodos 
ágeis, contribuem para a entrega de produtos com melhor mantenabilidade, 
extensibilidade e com menos defeitos. 


* Processo de Desenvolvimento Simplificado: Os método ágeis são, em re- 
gra geral, menos prescritivos do que os métodos tradicionais, definem menos 
papéis e menos artefatos. São mais facilmente compreendidos pela equipe, e 
oferecem maior margem para otimização e adaptação para a maior eficiência 
no contexto da organização em que está sendo aplicado. 


e Redução de Risco: O planejamento iterativo e as releases frequentes permitem 
que as prioridades do projeto sejam reajustadas constantemente. 


Métodos ágeis possibilitam que as incertezas do projeto, no nível dos requi- 
sitos, ou no nível técnico, sejam estimadas e distribuídas de forma inteligente 
nos releases, para manter o risco sempre balanceado. Além disso, as entregas 
em prazos curtos oferecem maior visibilidade da velocidade do time, ofere- 


cendo maior previsibilidade do prazo necessário para concluir o projeto. 


e Redução de Custos: Equipes ágeis são menos propensas a desenvolver fun- 
cionalidades de baixa prioridade ou que se tornaram desnecessárias ao longo 
do tempo [20]. Abordagens não ágeis geralmente tendem a cair nesse pro- 
blema devido ao grande espaço de tempo entre o levantamento dos requisitos 
e entrega do produto. 
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Figura 1.3: Scrum 


Scrum é um dos métodos ágeis mais populares na atualidade e tem foco maior nos 
aspectos gerenciais do desenvolvimento de software. Nele, cada iteração é chamada 
de sprint. Geralmente cada sprint tem um período de mês que pode variar de poucos 
dias a algumas semanas. As pessoas envolvidas no processo de desenvolvimento são 
dividas no Scrum em três papéis principais: o Scrum Master, o Product Owner (dono 
do produto) e a equipe. 

O Product Owner é o maior interessado no software, é aquele que teve (ou que 
representa quem teve) a necessidade do produto, e por isso tem a visão do produto. 
Define o que deve ser feito, e prioriza as funcionalidades a serem desenvolvidas, 
mantendo-as em um artefato chamado de product backlog, que nada mais é do que 
uma lista de todas as funcionalidades que devem ser implementadas, ordenadas por 
prioridade. 

É também responsabilidade do Product Owner passar toda a informação de ne- 
gócio que for necessária para que a equipe possa transformar suas ideias em software. 

A Equipe é composta por um número que varia de cinco a nove pessoas e é cross- 
funcional, isto é, há pessoas dos mais variados perfis, como testadores, desenvolve- 
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dores, designers, analistas de negócio etc. integrando a equipe. O principal objetivo 
dela é implementar as funcionalidades que foram selecionadas para serem desenvol- 
vidas na iteração e entregá-las em funcionamento ao final desse período. No capítulo 
6 abordaremos mais a fundo as vantagens de se trabalhar com equipes pequenas. 

O Scrum Master, também chamado de facilitador, é responsável por manter o 
processo em funcionamento, assegurando que todas as regras estão sendo aplica- 
das, e remover os impedimentos da equipe, isto é, resolver qualquer problema que 
possa atrapalhar o progresso do desenvolvimento, garantindo assim que o objetivo 
da iteração seja atingido. 

É importante ressaltar que o Scrum Master não atua como um gerente ou chefe 
da equipe porque ela é auto-organizável. O Scrum Master não determina o que cada 
membro da equipe deve ou não fazer: a equipe se compromete com a entrega das 
funcionalidades e, então, se auto-organiza, definindo por quem e em qual momento 
as tarefas serão realizadas. 

Toda sprint começa com uma reunião de planejamento, que é dividida em duas 
partes. A primeira delas tem um enfoque mais estratégico, na qual se decide o que 
será feito, isto é, quais funcionalidades serão implementadas e define-se uma meta 
para a Sprint. Para isso, o Product Owner apresenta os itens do product backlog, e a 
equipe obtém informações suficientes sobre cada um dos itens, dessa forma, é possi- 
vel fornecer uma estimativa que expresse um tamanho ou um número de horas para 
o trabalho e assim seja definido quantas e quais tarefas poderão ser desenvolvidas 
no sprint (de acordo com a velocidade da equipe que é calculada através de dados de 
sprints passados). 

Depois de definidas quais tarefas serão desenvolvidas no sprint, a equipe utiliza 
a segunda parte da reunião, que tem um enfoque mais tático, para decidir como 
serão feitas as tarefas. Então se analisa tarefa por tarefa com mais detalhes, mais 
informações de negócio são apresentadas e é possível tomar diversas decisões de 
negócio e decisões técnicas. 

Ao fim da reunião de planejamento a equipe começa a trabalhar nas tarefas, res- 
peitando as prioridades: fazendo sempre primeiro as tarefas mais importantes, que 
representam maior valor para o produto de acordo com o Product Owner. Todos 
os dias é realizada uma reunião para que a equipe converse sobre o andamento do 
sprint. Posteriormente apresentaremos em mais detalhes as reuniões. 

Ao longo da Sprint a equipe mantém sempre em mente a sua meta e quando o 
andamento das coisas foge do que foi previsto, ela pode negociar o escopo com o 
Product Owner, de forma que não comprometa a meta [59]. 
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TIMEBOXES 


O Scrum reforça a ideia de que todas as cerimônias do time preci- 
sam ter um timebox (tempo definido) e que é muito importante que es- 
ses tempos sejam respeitados para se manter um ritmo sustentável. Se 
as Sprints, por exemplo, tem duração de duas semanas, é importante que 
não sejam estendidas. Se a reunião diária dura 15 minutos, é importante 
que a reunião não seja estendida. Os timeboxes das outras reuniões va- 
riam de acordo o timebox da Sprint e e podem variar também de acordo 
com cada contexto da equipe. 

Os tempos sugeridos para um Sprint de 30 dias são [59]: 


e Reunião Planejamento: 8 horas. 
e Reunião de Revisão (Demonstração): 4 horas. 


e Reunião de Retrospectiva: 3 horas. 











Ao fim do sprint, mais duas reuniões acontecem: a reunião de revisão e a reu- 
nião de retrospectiva. Na reunião de revisão a equipe apresenta ao Product Owner o 
trabalho que foi desenvolvido durante o sprint, para que ele possa oferecer feedback, 
e aprovar ou não tudo o que foi produzido. Na reunião de retrospectiva os principais 
acontecimentos do sprint são apresentados e discute-se sobre as lições aprendidas e 
melhorias que podem ser aplicadas ao processo. 


1.6 EXCELÊNCIA TÉCNICA COM XP 


O método ágil Extreme Programming (em português Programação Extrema), mais 
conhecida simplesmente como XP, foi criado e inicialmente divulgado por Kent Beck 
nos anos 90, e é um dos métodos ágeis que melhor cobre aspectos técnicos do de- 
senvolvimento de software como codificação, design e testes, veremos mais detalhes 
a seguir. 

Segundo o XP, durante o processo de desenvolvimento há quatro atividades bá- 
sicas a serem executadas: Ouvir, Desenhar, Codificar e Testar. 


É preciso ouvir porque desenvolvedores nem sempre possuem o conhecimento 
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de negócio necessário para se construir o software. O Planning Game é uma reu- 
nião que acontece uma vez a cada iteração, em que o principal objetivo é decidir 
quais funcionalidades serão desenvolvidas na iteração e aprender mais sobre elas. O 
cliente escreve histórias de usuário em cartões que representam a necessidade de 
funcionalidade a ser desenvolvida, e explica para os desenvolvedores tudo o que for 
preciso para que eles possam implementá-la. 

Um bom design é uma excelente ferramenta para que todos possam compreender 
melhor os sistemas complexos, suas estruturas, dependências e regras de negócio. O 
principal objetivo é manter o design sempre simples, evitando aumentar a comple- 
xidade com a criação de funcionalidades que não sejam realmente necessárias. 

Essa é a máxima do principio YAGNI (You aren't gonna need it - Você não vai 
precisar disto) que basicamente diz que devemos fazer as coisas somente no mo- 
mento em que realmente precisarmos delas: muitas vezes antecipamos o desenvolvi- 
mento antes mesmo que surja a necessidade real, assumindo que um dia ela chegará, 
porém, essa necessidade pode nunca chegar. 

Ao manter o design simples e fazer somente aquilo que for necessário, você pou- 
pará tempo, porque deixará de escrever código que não precisa e terá mais tempo 
para se concentrar na qualidade do que realmente é necessário e que vai agregar va- 
lor para a demanda real e atual do cliente. 

Codificar é uma atividade essencial para o desenvolvimento de software, afinal 
de contas, sem código não existe software algum. Nessa etapa, é extremante impor- 
tante que o cliente continue acessível para que possa oferecer feedback e responder 
às diversas dúvidas que surgem durante o desenvolvimento. 

Com XP, os testes de unidade são escritos antes do código de produção (dis- 
cutiremos em detalhes mais à frente); todo o código fonte que será executado em 
produção é desenvolvido em pares; a integração do código fonte é realizada fre- 
quentemente através da prática de integração contínua; e o código fonte é coletivo, 
ou seja, pertence a todos os membros da equipe, e deve ser escrito de acordo com os 
padrões definidos pelo próprio time. 

Testar é uma atividade de extrema importância para garantir a qualidade do soft- 
ware e não é algo opcional com XP, ao contrário, todo código deve possuir testes de 
unidade, e todos os testes devem ser executados com sucesso antes que uma entrega 
seja feita. Quando um defeito é encontrado, cria-se um teste de unidade para asse- 
gurar que esse mesmo defeito jamais volte a acontecer. No XP os testes são escritos 
antes do código de produção através de TDD (Test Driven Development, ou Desen- 
volvimento Guiado por Testes). 
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Devido ao foco técnico de XP e ao foco mais gerencial do Scrum, muitas empre- 
sas os combinam para obter um processo mais completo, visando um processo mais 
eficiente. Estudaremos mais a frente cada uma das práticas citadas. 


1.7 FLUXO CONTÍNUO COM KANBAN 





Figura 1.4: Kanban 


Kanban é um método ágil que, diferentemente da maioria dos métodos ágeis, não 
possui iterações. Ao invés disso, desacopla o planejamento, priorização, desenvol- 
vimento e entrega, de forma que cada uma dessas atividades possa ter sua própria 
cadência para melhor se ajustar à realidade e necessidade que o processo demanda. 

Cadências são repetições que se sucedem em intervalos regulares. Este é um con- 
ceito do método Kanban que determina o ritmo de um determinado tipo de evento. 
Priorização, entregas, retrospectivas, e qualquer evento recorrente podem ter sua 
própria cadência. 

Métodos ágeis, no geral, controlam cadências através das iterações que geral- 
mente duram de uma a quatro semanas. Dentro de cada iteração, realiza-se planeja- 
mento, desenvolvimento, testes, revisões, retrospectivas etc. Tudo isso dentro de um 
período pré-definido. 

Já com Kanban o processo é um fluxo contínuo e não é preciso que todo o tra- 
balho planejado esteja concluído para que uma entrega seja realizada. No momento 
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da entrega, algumas tarefas estarão prontas e outras em progresso; as que estiverem 
prontas farão parte da entrega, e as que não estiverem ficarão para a próxima. 

Em meados de 2007, Rick Garber e David J. Anderson apresentaram nas confe- 
rências o “Lean New Product Development” e “Agile 2007”, os resultados prelimina- 
res do uso de Kanban na Corbis, uma empresa que vende imagens e clips de vídeo 
fundada por Bill Gates, da Microsoft. Desde então, o Kanban vem ganhando mais e 
mais força na comunidade de desenvolvimento de software e mais empresas passa- 
ram a adotá-lo. 

Kanban está bastante relacionado com o conceito de Pull Systems (sistemas de 
produção puxados), do Toyota Production System (TPS). Tradicionalmente, antes da 
Toyota, a grande maioria das indústrias utilizava o conceito de Push Systems (siste- 
mas de produção empurrada). 

Um sistema de produção empurrada caracteriza-se quando a primeira operação 
do processo recebe uma ordem de produção e a executa, empurrando o resultado da 
operação atual para a operação seguinte. Em sistemas empurrados, não há ligação 
direta entre o que é produzido e a demanda do cliente, ou seja, pode-se dizer que 
o fato de um item ter sido produzido não significa que um outro item tenha sido 
vendido. 

Já um sistema de produção puxada exige que cada operação do processo seja 
alimentada pela demanda da etapa anterior, estabelecendo uma ligação direta entre 
o consumo real do cliente e a quantidade produzida. Dessa forma, o fato de um item 
ter sido vendido, geraria a demanda para a fabricação de outro. Em uma abordagem 
de desenvolvimento de software, poderíamos dizer que a demanda para se trabalhar 
em uma nova funcionalidade seria gerada quando alguma outra fosse entregue. 

Kanban é uma palavra japonesa que significa cartão sinalizador. É utilizado no 
Sistema Toyota de Produção (TPS) e também por diversas empresas que aderiram à 
filosofia Lean para representar, em um sistema puxado de produção, um sinal para 
que se puxe mais trabalho, ou seja, para que o processo seja alimentado. 

Kanban é dos métodos de desenvolvimento de software menos prescritivos, que, 
de acordo com Henrik Kniberg, possui apenas três prescrições [34]: 


1) Visualizar o fluxo de trabalho (workflow); 
2) Limitar o trabalho em progresso; 


3) Gerenciar e medir o fluxo. 
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Kanban incentiva a adaptação baseada em contexto. Deste modo, parte-se da 
premissa que não existe uma única solução que resolva todos os problemas de to- 
dos os diferentes contextos, e por isso há a necessidade de adaptação, em que cada 
processo deve se adequar às necessidades do contexto a que pertence. 

Kanban também recomenda que se meça o lead time, tempo médio para se com- 
pletar um item, de forma que o processo deve ser continuamente otimizado para 


tornar esse tempo cada vez menor e mais previsível. 


1.8 QUAL É O MELHOR MÉTODO? 


Kniberg define ferramenta como “qualquer coisa que possa ser usada para atingir 
uma tarefa ou objetivo”, e processo como “a forma que se trabalha” [34]. Para ele, 
métodos como Scrum, XP e Kanban são ferramentas para processos, e questionar 
qual é o melhor deles é o mesmo que comparar se um garfo é melhor do que uma 
faca, ou seja, isso depende do contexto e do objetivo em questão. 

Nenhum método é completo e nenhum é perfeito, por isso, sinta-se livre para 
combinar as ferramentas e aproveitar o que funcionar melhor para seu contexto, ou 
seja, considerando a cultura da sua organização, as habilidades da sua equipe e as 
restrições de seu projeto. É comum, por exemplo, que se adote práticas de engenha- 
ria de XP, como programação em par e integração contínua, em times que utilizam 
Scrum. 

Todo projeto de desenvolvimento de software é diferente, possui pessoas com 
habilidades diferentes, níveis de experiência diferentes, orçamento, prazo, escopo e 
riscos diferentes. Os valores da organização e suas metas também são específicos, 
e com toda essa variação, sem dúvida, as restrições também serão diferentes. Por- 
tanto, você deve procurar compreendê-las de forma a explorá-las da melhor maneira 
possível visando atingir bons resultados. 

Assim como as práticas, os papéis em uma equipe ágil, podem variar de acordo 
com o método utilizado e contexto da equipe. Fique atento para utilizar apenas pa- 
péis que de fato agreguem valor, e para não incluir papéis conflitantes. 

Cada novo método que você estuda e conhece é mais uma ferramenta para sua 
caixa de ferramentas, a pergunta certa não é “qual é o melhor método”, mas “qual o 
método mais adequado para esse contexto”, e então, munido de sua caixa de ferra- 
mentas, você terá condições de escolher a melhor abordagem para cada desafio. 
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1.9 E AGORA, O QUE EU FAÇO AMANHÃ? 


Revise os quatro valores ágeis: você acredita que sua organização reflete esse valores? 
Se não, o que poderia ser feito diferente para que isso melhorasse? 

Reflita sobre seu projeto atual: Você e seus colegas estão de fato trabalhando 
colaborativamente em equipe? Estão entregando software em funcionamento com 
numa frequência adequada? Como vocês lidam com as mudanças de prioridade de 
negócio do cliente? Quais são os benefícios que você espera alcançar com a utiliza- 
ção de métodos ágeis em suas equipe? O que métodos ágeis podem trazer de positivo 
para seu cliente? Como podem beneficiar sua equipe? Verifique cada um dos bene- 
fícios listados neste capítulo e pense se estão em alinhamento com o que você espera 
melhorar em sua organização. 

Pense nos diferentes papéis e práticas de sua equipe. Todos eles de fato estão 
agregando valor ao projeto? 
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CAPITULO 2 


Fluéncia Agil 


Em um experimento cientifico [58], um grupo de cientistas colocou cinco macacos 
numa jaula. No meio da jaula, havia uma escada e sobre ela, um cacho de bananas. 
Quando um macaco subia na escada para pegar as bananas, os cientistas jogavam 
um jato de agua fria nos outros macacos que estavam no chao. 

Depois de certo tempo, quando um macaco tentava subir na escada, os outros 
batiam nele (com medo de tomar outro jato). Depois de algum tempo, nenhum 
macaco subia mais a escada, apesar da tentação das bananas. 

Os cientistas, então, trocaram um dos macacos por outro novo. Quando ele ten- 
tou subir a escada para pegar as bananas, também apanhou dos outros. Outro ma- 
caco foi substituído e o mesmo episódio se repetiu por diversas vezes, e inclusive os 
novos macacos aprenderam a bater nos outros que tentavam pegar as bananas. 

Depois de algum tempo, todos os macacos foram substituídos, porém o hábito 
permaneceu, e mesmos os macacos que nunca viram o jato d'água continuavam ba- 
tendo naqueles que tentavam subir para pegar bananas. 


Se fosse possível perguntar a algum deles porque eles batiam em quem tentasse 
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subir a escada, com certeza a resposta seria algo do tipo: “Não sei, mas as coisas 
sempre foram assim por aqui”. 

Você já viu alguma coisa desse tipo acontecer nas empresas em que trabalhou? 
Alguma regra que já não faz mais sentido, mas que, porém, continua sendo utilizada 
por todos, mesmo sem que saiba o motivo? Infelizmente, isso não é tão incomum, e 
inclusive equipes ágeis podem cair nesse engano. 

Métodos ágeis ganharam bastante popularidade e, atualmente, vêm sendo utili- 
zados por grande parte das organizações que desenvolvem software, mas essa popu- 
laridade também trouxe alguns problemas. 

Muitos passaram a se interessar por métodos ágeis apenas porque grandes 
players do mercado estão utilizando, porém não buscaram entender a essência (co- 
laboração, agregar valor de negócio, entregas frequentes etc.), e ficaram apenas na 
forma (quadros na parede, estimativas com cartas, backlogs, etc.). 

Diana Larsey e James Shore [57] afirmaram que muitos líderes de organizações 
ainda se queixam de que não estão conseguindo alcançar os benefícios que esperam 
com a adoção de métodos ágeis e, por isso, desenvolveram um modelo de fluência 
ágil para ajudar as organizações a alcançarem esses benefícios com mais eficiência. 

Para Larsey e Shore, a fluência ágil diz respeito à maneira com que a equipe res- 
ponde quando está sob pressão: “Qualquer um pode seguir um conjunto de práticas 
quando há tempo para focar em uma sala de aula, mas a verdadeira fluência requer 
habilidade e prática frequente que persiste mesmo quando sua mente está distraída 
com outras coisas, é uma questão de hábitos”, 

Essa fluência ágil está relacionada não apenas com a capacitação dos membros da 
equipe, mas também com as estruturas de gestão, com os relacionamentos, a cultura 
organizacional e práticas da equipe. 


Para conquistar a fluência ágil, uma equipe deverá passar por 4 estágios distintos: 


1) Foco no Valor (Atuar na Cultura na Equipe). 
2) Entrega de Valor (Atuar nas Habilidades da Equipe). 
3) Otimização de Valor (Atuar na Estrutura Organizacional). 


4) Otimização Sistêmica (Atuar na Cultural Organizacional). 


Ao longo deste livro, nós exploraremos o que você pode fazer para ajudar sua 
equipe e sua organização a trilhar esse caminho que os levará a um melhor apro- 
veitamento dos benefícios que os métodos ágeis podem oferecer. E para que não 
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façamos como os macacos, nós vamos buscar entender não apenas a forma das prá- 
ticas, mas também a essência de cada uma delas. 


2.1 EVOLUÇÃO E MATURIDADE DE UMA EQUIPE ÁGIL 


“Unir-se é um bom começo, manter a união é um progresso, e trabalhar em conjunto é 
a vitória” 
— Henry Ford 


Sempre que uma nova equipe é formada, naturalmente, um processo de maturi- 
dade acontece [51]. É notável que um equipe que acabou de se formar não trabalha 
com a mesma produtividade e dinamismo que uma equipe cujas pessoas já tiveram 
algum tempo para se conhecer, os seus pontos fortes e suas dificuldades. 

Métodos ágeis requerem verdadeiras equipes, não apenas grupos [53]. E verda- 
deiras equipes ágeis são formadas de pessoas, com uma diversidade de habilidades, 
que trabalham colaborativamente com uma visão compartilhada para atingir deter- 
minados objetivos. 

As pessoas precisam trabalhar algum tempo juntas e passar por todos esses está- 
gios, por isso não se deve mover pessoas de uma equipe para outra com alta frequên- 
cia, como se fossem peças de xadrez, essa instabilidade toda pode destruir a integri- 
dade do time. Isso não significa que de vez em quando não seja interessante que 
as pessoas mudem de equipe para que possam diversificar suas experiências, mas é 
preciso encontrar um ponto de equilíbrio saudável. Ambos os extremos são inefici- 
entes. 

No artigo “Your Path to Agile Fluency”, Diana Larsey e James Shore [57] afirmam 
que o “turnover é a principal causa da perda de fluência em uma equipe ágil, e que 
quando uma equipe ganha ou perde membros, enfrenta problemas para sustentar 
aquilo que já havia sido aprendido” 

Em 1977, Bruce Tuckman, criador da teoria das dinâmicas de grupos, publicou 
uma artigo chamado “Estágios de Tuckman” que descreve esse processo de maturi- 
dade em quatro estágios: Formação, Confronto, Normatização e Performance (veja 
na figura 2.1. 
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SY 


Performance <—— | Normatização 








Figura 2.1: Estagios de Tuckman 


Cada um dos estágios citados anteriormente possui algumas características pró- 
prias: 

1. Formação: Este é o primeiro estágio pelo qual uma equipe recém formada 
passará, é o momento em que os membros da equipe começam a conhecer uns aos 
outros, procuram entender quais são as habilidade de cada um, e as tendências de 
comportamento de cada pessoa. Nesse estágio também se estabelecem os primeiros 
objetivos coletivos e completam-se algumas tarefas, mas a ênfase das pessoas ainda 
é mais individual do que coletiva. 

2. Confronto: Conflitos aparecem à medida que diferentes ideias para atingir 
objetivos vão surgindo e as metas coletivas identificadas no estágio de formação são 
questionadas. Alguns membros podem se abalar por essa situação. Uma liderança 
forte é extremamente importante para que a equipe passe por este estágio. 

3. Normatização: É neste estágio que as pessoas realmente passam a priorizar 
os objetivos coletivos da equipe sobre os objetivos individuais de cada membro, por 
isso, a equipe consegue entrar em consenso mais facilmente. 

4.Performance: A equipe já possui todas as competências necessárias para atin- 
gir seus objetivos, todos estão comprometidos e motivados, e atuam com verdadeiro 
espírito de equipe, pensando em termos de “nós” em vez de “eu” ou “eles”. Conflitos 
são facilmente solucionados. 
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Maturidade Ágil 


Além de uma equipe unida e forte que saiba trabalhar colaborativamente, é pre- 
ciso aprender a se trabalhar com métodos ágeis, e amadurecer na utilização das prá- 
ticas ágeis. 

A arte marcial Aikido, utiliza um método de aprendizagem desenvolvido no Ja- 
pão a mais de 4 séculos atrás chamado Shu-Ha-Ri [17] (figura 2.2) que consiste em 
três níveis de habilidade que podem ser utilizados como referência para qualquer 
nova prática, habilidade ou competência a ser aprendida, inclusive métodos ágeis. 
Os três estágios são: 


Tp pI. 
N 
Shu Ha Ri 


Figura 2.2: Shu Ra Hi 


1. Shu: Representa o primeiro estágio da aprendizagem de uma habilidade, em 
que é necessário se construir a base, a fundação do que se está aprendendo. 

O aprendiz busca observar, copiar e imitar o que alguém que já tem experiência 
faz, geralmente, um mestre. Neste estágio é mais eficiente seguir regras do que tentar 
improvisar ou modificar técnicas. 

Uma equipe que está começando a trabalhar com métodos ágeis, certamente, por 
algum tempo estará nesse estágio. É um momento importante para seguir as regras 
do método numa abordagem “by-the-book”, ou seja, sem alterações ou improvisos. 
Se uma equipe está utilizando Scrum, neste estágio, por exemplo, é importante que 
todos os papéis sejam assumidos, e que todas as reuniões sejam realizadas de acordo 
com as “regras”. Esse é um momento em que pode ser importante procurar ajuda de 
alguém que tenha experiência com métodos ágeis. 

2. Ha: Esse é o segundo estágio, em que o estudante já começa a pensar mais pro- 
fundamente sobre os porquês das coisas, quebra algumas regras, e rompe um pouco 
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com a tradição. Agora, já é possível refletir sobre o que foi aprendido e compreender 
melhor os princípios em vez de apenas repetir ou seguir regras. 

É nesse estágio que algumas adaptações ao contexto podem começar surgir, no- 
vas práticas são inseridas, e insights de experiências passadas servem como base para 
tomadas de decisão. Agora, mesmo que as coisas mudem um pouco em sua forma 
(práticas, papéis, reuniões), a equipe estará pronta para manter a essência da agili- 
dade (entregas frequentes, respeito às pessoas, comprometimento, colaboração, co- 
municação etc.). 

3. Ri: Neste último estágio, a prática já se torna parte de quem está aprendendo e, 
apesar de ainda seguir algumas regras (mesmo aquelas que foram quebras e reinven- 
tadas) [4], tudo parece ser natural, e o aprendizado vem da prática e da experiência. 

É importante notar que uma equipe pode estar em estágios diferentes depen- 
dendo da referência, por exemplo, um time pode estar no estágio Ri em se falando 
de entregas frequentes, mas pode estar no estágio Shu em relação à programação em 
par. 

Uma lição importante deste modelo é que há um momento certo de maturidade 
para se quebrar as regras, adaptar e improvisar. Um aluno iniciante (no estágio Shu) 
de artes marciais que tentar mudar os movimentos ensinados pelo mestre poderá 
facilmente fazer algo errado e se machucar, já um aluno intermediário (no estágio 
Ha), provavelmente, estará mais preparado para encontrar seu próprio estilo sem 
correr altos riscos. 

O mesmo ocorre com uma equipe que está utilizando métodos ágeis, se num 
momento precoce tentar adaptar ou quebrar as regras, antes de ter compreendido 
mais profundamente os princípios, corre o risco de estar fazendo alguma outra coisa 


qualquer e as continuar chamando de métodos ágeis. 


2.2 ORDEM, CAOS E COMPLEXIDADE 


Assim como há muitos tons de cinza entre o preto e o branco, entre o caos (de- 
sordem) e a ordem, há também alguns níveis [8]. Quando tentamos trazer nossas 
organizações para o extremo da ordem, para que possamos tornar as coisas mais 
previsíveis e manter tudo sob controle, criamos uma série regras, e enrijecemos o 
sistema, tornando-o pouco adaptativo e burocrático. Por outro lado, quando não 
há nenhuma regra, nenhuma restrição, nenhum líder, o sistema se encontra no que 
chamamos de caos sem nenhuma previsibilidade e você não consegue ter a menor 


ideia do que está acontecendo ou para aonde as coisas estão caminhando. 
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Para ilustrar a diferença entre a Ordem e o Caos, imagine que você está indo 
com sua família passar o final de semana na praia. Você tem dois filhos pequenos 
e danados, um menino, e uma menina. Seu cônjuge foi fazer um caminhada e você 
ficou responsável pelas crianças. Se você optar pelo Caos extremo, não dirá nada para 
as crianças e as deixará completamente livres para fazerem aquilo que quiserem, não 
as advertirá, não haverá limites, nem restrições, nem regras. Liberdade total, tudo é 
possível! Nem é preciso falar que a probabilidade de uma criança se afogar e a outra 
entrar no meio de um jogo de futebol e tomar uma bolada é bem alta. 


Agora, se você optar pela ordem extrema, dirá a seus filhos: 


Sentem-se aqui na minha frente, brinquem de fazer castelo com 500 metros de altura 
e duas torres, usem o balde e as pazinhas, não saiam daqui enquanto eu não 
autorizar, não chorem, não gritem, não levantem, e (imagine e inclua mais umas 50 
regras aqui). 


Num contexto totalmente ordenado, todas as variáveis devem ser isoladas, e por 
isso é possível prever acontecimentos, porém, note que ambos os extremos são exa- 
gerados. No primeiro, as crianças acabam se machucando por excesso de liberdade 
e negligência, no segundo exemplo, as crianças mal podem se divertir pois preci- 
sam seguir ordens restritas e não têm liberdade alguma para se auto-organizar ou 
expressar sua individualidade e criatividade. 

O meio termo entre esses extremos, seria dar às crianças algumas restrições bá- 
sicas para certificar-se de que elas poderão brincar sem que nada de mal ocorra a 
elas. Você diria algo do tipo: - “Crianças podem brincar do que quiserem, e fiquem 
onde eu possa vê-los, e não deixem que a água ultrapasse a cintura de vocês” 

Agora pense em uma equipe de desenvolvimento de software que não possui 
nenhuma regra comum entre os membros da equipe, cada um escreve código da 
maneira que acha melhor, uns escrevem testes outros não, alguns utilizam certas 
convenções, outros utilizam outras, cada um trabalha em sua linguagem de progra- 
mação preferida, alguns trabalham no escritório outros de casa, cada um define sua 
frequência de integração do código. 

Dá pra imaginar que esse cenário seria um bagunça, não é? Por outro lado uma 
equipe que está no extremo da ordem possui regras para tudo, não tem nenhuma 
liberdade para expressar sua criatividade ou para solucionar os problemas, todos os 
horários estão definidos, as tecnologias, as linguagens de programação, o que se pode 
fazer, o que não se pode fazer. Há pouca ou nenhuma variação. 
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Os métodos ágeis são uma resposta ao caos e à ordem, e propõem um cenário 
que está justamente no meio termo: a complexidade [8] (veja na figura 2.3. Muitos 
autores chamam isso de a “beira do caos”. Você só precisa de um pouco ordem para 
que o sistema possa se auto-organizar para atingir um determinado objetivo. Não 
mais do que isso. E essa “ordem” geralmente está presente nos métodos ágeis na 
forma de restrições. 


Agilidade 





Figura 2.3: Complexidade 


“Toda organização é um sistema complexo adaptativo, é como um jogo em que as 


regras são mudadas ao longo do curso, e pelos próprios participantes” 
— Jurgen Appelo 


Pense no Scrum, como um exemplo. A equipe precisa possuir de 5 a9 membros. 
Todos os dias o time deve fazer uma reunião diária de até 15 minutos. Toda iteração 
tem como resultado um potencial incremento no produto etc. Essas regras e restri- 
ções asseguram que a equipe trabalhe em um estágio intermediário entre a ordem e 
o caos. Tudo aquilo que fica implícito é espaço para que ela possa se auto-organizar e 
adaptar-se para realizar o melhor trabalho possível no contexto em que está inserida. 

Em uma abordagem ágil, o trabalho do gestor não é criar regras na organização, 
mas certificar-se de que as pessoas podem criar suas próprias regras juntas, e é jus- 
tamente esse esforço conjunto que permite que o sistema alcance “a beira do caos” 
[8]. Nessa visão a gestão ocupa-se apenas com algumas restrições de alto nível. O 
resto pode ser definido pela própria equipe, e é nesse cenário que a auto-organização 
acontece, porque ela tem liberdade para criar suas próprias regras e tomar decisões. 
Quando todas as decisões vêm de cima para baixo, não há auto-organização. 

Auto-organização requer empoderamento, e empoderamento requer confiança. 
A gestão precisa fazer um investimento de autonomia para que equipe possa tomar 
decisões e se organizar da forma mais eficiente para atingir os objetivos da organi- 
zação. 
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Outro ponto importante, é que a auto-organização por si só, não é boa, nem 
ruim e pode levar a qualquer resultado. Por isso é essencial que a equipe se auto- 
organize em torno de um objetivo, de metas importantes para o sucesso. É como se 
a gestão apontasse aonde a organização quer chegar e qual é a direção a seguir, mas a 
equipe tivesse autonomia suficiente para decidir qual é a melhor forma de se chegar 
até lá. 


2.3 E AGORA, O QUE EU FAÇO AMANHÃ? 


Faça um levantamento do turnover da sua equipe. Quantas pessoas deixaram a 
equipe nos últimos seis meses, e quantas novas pessoas foram recebidas? Reflita so- 
bre o impacto dessas mudanças na produtividade da sua equipe. Vocês rotacionam 
os membros das equipes de tempos em tempos? Isso foi bom ou ruim? Por quê? 
Qual tem sido o impacto dessas mudanças na performance da equipe? 

Pense em qual dos estágios Tuckman sua equipe se encontra no seu ponto de 
vista em relação à agilidade. O que pode ser feito para vencer os desafios atuais e 
seguir para o próximo estágio? 

Converse com sua equipe sobre os seus objetivos. Vocês sabem qual é o papel de 
vocês na organização? Caso estes objetivos não estejam claros, procure compreendê- 
los, conversar com a gestão, e torná-los explícitos para que toda a equipe saiba para 
onde estão indo e aonde devem chegar. 

A equipe tem liberdade para decidir qual a melhor forma de atingir seus obje- 
tivos, ou as decisões são impostas pela gestão? Discuta com sua equipe sobre como 
vocês podem ganhar mais confiança da gestão para criar um ambiente mais favorável 
à auto-organização. 

Pense sobre as quais são as regras da sua equipe. São realmente necessárias? Será 
que alguma delas foi útil no passado mas agora já perdeu o sentido? 
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Foco em Valor para o Negócio 


Não é incomum ouvirmos histórias de times que passaram anos construindo um 
produto que ninguém jamais usou, ou então de equipes que passaram meses otimi- 
zando um produto para que ele tivesse máxima performance e escalabilidade, cons- 
truindo sempre com tecnologia de ponta, mas a primeira frase do cliente ao ver o 
produto funcionando é “Não era bem isso que estava querendo”, 

Todo produto de software representa de alguma forma valor para alguém e esse 
é o principal motivo da existência do software, mas apesar de parecer algo óbvio, 
muitas vezes o perdemos de vista e acabamos construindo um produto que pode até 
ser tecnicamente fantástico, mas que não agrega o valor de que o cliente precisa. 

É por isso que métodos têm foco em valor de negócio, e o primeiro estágio da 
fluência ágil diz respeito a agregar valor de negócio ao cliente e a melhorar a visibi- 
lidade do trabalho da equipe [57]. 

O objetivo é aprender a deixar de planejar apenas em termos técnicos, e 
preocupar-se em planejar levando em conta o valor de negócio que o software de- 
senvolvido poderá agregar ao cliente, assim como refletir e decidir sobre quais as 
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melhores maneiras de potencializá-lo. 

Para dar suporte a esse objetivo as equipes ágeis fazem uso de ferramentas como 
backlogs, iterações e quadros kanban. 

Os principais benefícios alcançados neste estágio são: a transparência, que per- 
mite que o progresso (ou a falta de progresso) do time seja facilmente visualizado 
por todos, inclusive pela gestão, a melhoria contínua para se agregar a cada itera- 
ção mais e mais valor, e um melhor alinhamento que resultará em uma equipe mais 
colaborativa, com menos maus entendidos e menos atrasos desnecessários. 

É o momento em que a equipe deverá ganhar maturidade para responsabilizar-se 
pelo resultado do trabalho, não apenas em termos técnicos, mas também em termos 
do valor de negócio agregado, e mais do que isso, devem responsabilizar-se pelo 
resultado do time e não apenas por suas contribuições individuais. 

É claro que para que a equipe tenha essa visão de valor em termos de negócio é 
essencial a presença de alguém com um perfil de negócios próximo para ajudá-los a 
compreender o que de fato é de valor e o que não é. 

Quanto mais cedo for possível agregar valor ao cliente, melhor será o resultado. 
Quando o cliente recebe o software funcionando em um curtos intervalos de tempo, 
além de ganhar vantagem competitiva, o trabalho em progresso também diminui 
(WIP). Consequentemente, a quantidade de trabalho parcialmente pronto diminuirá 
o desperdício, conforme abordado anteriormente. 

A Dell Computadores, por exemplo, não acumula estoques e entrega pedidos 
personalizados em menos de uma semana e, exatamente por não possuir estoques 
acumulados, pode oferecer a seus clientes novos produtos antes de seus concorrentes, 
sem ter que se preocupar em queimar estoques de produtos antigos. 

Assim como a faz a Dell, uma equipe de software que entrega rapidamente e man- 
tém um baixo nível de trabalho parcialmente pronto pode responder rapidamente a 
novas necessidades que venham a surgir sem se preocupar em deixar o trabalho que 
já foi começado para trás. 

As organizações que entregam rapidamente estruturam -se de forma que as pes- 
soas saibam como o trabalho deve ser feito sem que alguém precise dizer a elas o 
que fazer [48]. Essas pessoas devem ser capazes de resolver problemas e fazer adap- 
tações para responder a mudanças. Essas diretrizes são profundamente aplicadas na 
Toyota. 

Entregar rapidamente é complementar ao princípio de tomar decisões no úl- 
timo momento possível. Por exemplo: se o cliente recebe entregas de software toda 
semana, não precisa decidir sobre o que será feito daqui a nove meses. Entretanto, 
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se o cliente recebe software somente a cada três meses, então precisará decidir sobre 
as novas funcionalidades no mínimo três meses antes de poder vê-las em funciona- 
mento. 

Nesse capítulo abordaremos como equipes podem aplicar práticas ágeis para ga- 
rantir que o cliente receba valor de negócio com frequência através da entrega itera- 


tiva de software em funcionamento. 


3.1 DISSEMINANDO A VISÃO DO PROJETO 


Projetos sempre nascem de ideias de pessoas. Ideias que, geralmente, nascem de ten- 
tativas de tornar um determinado processo mais eficiente. Seus donos são chamados 
de visionários, porque eles possuem a visão do projeto e, entendem a necessidade e 
conhecem o problema que o software deve resolver. A visão revela para onde o pro- 
jeto está indo e por que ele está indo para lá. 

Todo projeto possui um ou mais visionários, alguém que conseguiu enxergar 
uma necessidade e teve uma ideia de solução para suprir essa necessidade. Ainda 
que um projeto possua muitos visionários, é necessário que alguém tome a responsa- 
bilidade de promover e comunicar essa visão à equipe de desenvolvimento e a todos 
os outros interessados no projeto. 

Esse papel, geralmente, é de responsabilidade do gerente de projetos, do próprio 
cliente, ou de alguém que represente o cliente. No método Scrum, por exemplo, a 
visão do projeto é responsabilidade do Product Owner. 

É muito importante que o visionário esteja bem próximo à equipe de desenvol- 
vimento para esclarecer as frequentes dúvidas que surgem ao longo do projeto. Por 
isso, um dos princípios do método XP é ter o Cliente Presente. Uma vez que todos 
forem contagiados com a visão do projeto, as chances de sucesso se tornam muito 
maiores. 


Há três perguntas essenciais que o visionário precisa comunicar à equipe: 
1) Que objetivo o projeto deve atingir? 
2) Por que esse projeto agregará valor? 
3) Como medir se o projeto foi bem sucedido? 


Para que a equipe possa desenvolver um software alinhado com a visão do pro- 
jeto, é necessário que a visão esteja sempre acessível para todos, por isso a importân- 
cia do visionário estar presente na equipe. 
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Muitas equipes mantêm uma breve descrição da visão, como por exemplo, a res- 
posta das três perguntas acima, em um wiki ou portal interno, ou até mesmo im- 
presso e anexado ao quadro da equipe. O importante é que esteja ao alcance de 
todos. 

Os visionários devem estar presentes nos momentos de tomada de decisão, nas 
reuniões de planejamento, nas apresentações de demonstração das iterações ou reu- 
niões de revisão. Se isso não acontecer, provavelmente a equipe não entenderá o 
propósito do produto que estão desenvolvendo. Poderíamos comparar isso a um 
médico que faz uma cirurgia, que não sabe de que mal está tentando livrar o paci- 
ente. 

Equipes de desenvolvimento de software tomam milhares de pequenas decisões 
todos os dias, e sem uma boa visão geral e contexto do que está sendo construído, é 
muito difícil tomar boas decisões. 

Como grande parte das equipes ágeis adotam um único representante da visão 


do produto, de agora em diante, o visionário será referido como Product Owner ou 
PO. 





SERÁ QUE TODOS ESTÃO NA MESMA PÁGINA? 


Marc Benioff, CEO da Salesforce.com, conta que um certo dia esta- 
vam no elevador um testador, um engenheiro, e um desenvolvedor de sua 
empresa. De repente alguém de outro conjunto entrou no elevador e per- 
guntou a eles “o que exatamente a Salesforce.com faz?” Para a surpresa 
do CEO, cada um deu uma resposta diferente [5]. 

Depois deste evento, Benioff tomou uma série de providências para 
garantir que todos “estivessem na mesma página” e depois de algum 
tempo investindo em disseminar essa visão, além de todos ganharem 
mais assertividade e conhecimento do que estavam fazendo, todos os 
membros da equipe de tornaram “potenciais marqueteiros e vendedo- 
res” do produto. 











Quando o projeto possui uma visão única e coesa, a tomada de decisão se torna 
muito mais fácil, e todos os membros da equipe, de posse da visão, podem partici- 
par mais ativamente, oferecer sugestões, e realizar um trabalho mais produtivo e de 
melhor qualidade. 
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O Discurso do Elevador 


Imagine que você entrou no elevador, e encontra, ninguém menos do que aquele 
investidor que você sempre sonhou que pudesse se interessar em seu produto. Você 
tem poucos segundos até que o elevador o deixe em seu andar, e precisa aproveitar 
a oportunidade para falar sobre o que você e sua equipe estão fazendo. O que você 
dirá a ele? 

A ideia por detrás do discurso do elevador é encontrar uma forma de transmitir a 
essência de uma ideia em um espaço muito curto de tempo [49]. Fazer esse exercício 
o ajudará a trazer mais clareza e objetidade para sua visão e será útil para pensar no 
produto sobre o ponto de vista do cliente e de que forma o produto agregará valor a 
ele. 

A Harvard Business School criou um website que ajuda a criar o Discurso do 
Elevador para seu produto, além de fazer uma análise com sugestões para que você 
possa melhorar seus discurso [54]. De acordo com a HBS seu discurso deve contem- 
plar os seguintes itens: 


1) Quem: O que você mais quer que seu ouvinte se lembre a respeito de sua organi- 
zação ou produto? 


2) O quê: De que forma seu produto agregará valor e trará resultados ou impactará 
o negócio de seu ouvinte? 


3) Por quê: Quais são os benefícios exclusivos, os diferenciais que seu produto ofe- 
rece? 


4) Objetivo: O que você espera que o ouvinte faça? 


Criar um discurso do elevador para seu produto pode ser uma forma divertida e 
rápida para desenvolver uma mensagem objetiva e convincente, ideal para apresentar 
seu produto para toda a sua organização e para potenciais clientes. 


3.2 PLANEJAMENTO E DESENVOLVIMENTO ITERATIVO 


O planejamento permite entender a expectativa do cliente em relação ao projeto e 
traçar estratégias para atendê-las. É o momento de entender as ideias e necessidades 
do cliente e descobrir as funcionalidades que o software precisará oferecer. 
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No desenvolvimento ágil de software o time inteiro está envolvido em definir 
requisitos, otimizá-los, implementá-los, testá-los, integrá-los, e entregá-los aos cli- 
entes [37]. Além disso, em um ambiente ágil, planejar é uma atividade constante. 
Dessa forma, é possível responder rapidamente às mudanças e realizar as adapta- 
ções que forem necessárias para que o software seja entregue com o máximo grau de 
qualidade e eficiência. 

Nos métodos ágeis os projetos são divididos em iterações curtas que geralmente 
têm uma ou algumas poucas semanas de duração. A cada iteração é realizada uma 
reunião de planejamento para definir o que será feito durante a iteração. O seu ob- 
jetivo é identificar junto ao cliente o que poderá agregar mais valor ao negócio. 

O processo de planejamento no método XP é chamado de “Jogo do Planeja- 
mento” no Scrum simplesmente de Planejamento. O objetivo do jogo do planeja- 
mento é garantir que o máximo de valor possível será gerado no dia a dia de trabalho 
através da criatividade e das habilidades da equipe. 

O planejamento da iteração acontece em uma reunião no início de cada iteração. 
É importante que nesta reunião estejam presentes a equipe de desenvolvimento e o 
cliente. Assume-se que o cliente tem toda a informação necessária no que diz res- 
peito ao que agrega valor ao software, e que a equipe de desenvolvimento tem toda 
a informação necessária em relação a quanto custa para agregar tal valor. 

A grande sacada é minimizar os custos e maximizar o valor agregado. Atra- 
vés da estimativa, os desenvolvedores podem dizer quanto custa, em outras pala- 
vras, quanto tempo leva para desenvolver determinada funcionalidade; e através da 
priorização, o cliente pode definir quanto valor uma história pode agregar, ou seja, 
quais funcionalidades podem trazer mais benefícios. Temos então uma relação de 
custo/benefício. 

Através dessa colaboração entre a equipe de desenvolvimento e o cliente é pos- 
sível traçar um plano para atingir sucesso no projeto. O jogo do planejamento é 
dividido em duas fases: o planejamento de releases e o planejamento de iterações. 

Um dos principais benefícios do planejamento iterativo é a eliminação do des- 
perdício de uma longa análise prematura, que é considerado um dos maiores des- 
perdícios no desenvolvimento de software [49]. É comum em projetos waterfall que 
a análise de todos os requisitos seja feita de antemão, de forma que no momento 
do desenvolvimento os requisitos já mudaram e da maneira que foram analisados já 
não podem mais agregar valor ao cliente. Essa prática de levantamento prematuro 


de requisitos é conhecida como Big Requirements Up Front (BRUP). 
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BACKLOGS DEEP 


Para ajudar Product Owners a não caírem no erro do levantamento 
prematuro de requisitos, Mike Cohn, criou o acrônimo DEEP [20] que 
representa 4 qualidades de um bom backlog: 


1) D - Detalhado Apropriadamente: Os itens de maior prioridade devem 
ser mais detalhados e os itens de menor prioridade não precisam de 


muitos detalhes. 


2) E - Estimado: Se todos os itens do Backlog estiverem estimados pela 
equipe, o PO terá mais facilidade em priorizar o backlog e terá melhor 
previsibilidade do projeto. 


3) E - Emergente: O Product Backlog é um artefato vivo, isto é, deve mu- 
dar frequentemente de acordo com as mudanças de negócio. Novos 
itens são incluídos, itens antigos são removidos ou modificados. 


4) P - Priorizado: Os itens do backlog devem estar priorizados do maior 
valor de negócio para o menor valor de negócio para que os itens mais 
importantes sejam detalhados e implementados antes dos menos im- 


portantes. 











Além disso, em abordagens tradicionais, era muito comum que os requisitos fos- 
sem transmitidos ao desenvolver apenas por escrito através de um documento. Em 
contrapartida, a essência da comunicação nos métodos ágeis é a comunicação face 
a face. 

De acordo com Alistair Cockburn, a comunicação através de papel é fria e pobre, 
porque não há oportunidade para perguntas e respostas, a comunicação entre pes- 
soas face a face é quente e muito mais rica porque oferece a oportunidade de iteração 
entre as partes [17]. 

É claro que isso não torna, de forma alguma, a comunicação escrita irrelevante, 
pelo contrário, ela também é importante, mas não é suficiente, e nem mais eficiente 
em todos os cenários. 

É por isso que muitos métodos ágeis defendem a ideia de uma reunião de pla- 
nejamento em que a equipe e o Product Owner participem juntos, e que, através de 
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uma conversa, criem histórias de usuário que representam as funcionalidades a se- 
rem implementadas no software. 

Ao decorrer deste capítulo, o conceito de histórias de usuário será mais ampla- 
mente explorado, mas, antes disso, explicaremos um pouco mais o que se faz em um 
planejamento de iteração. 


3.3 PLANEJANDO UMA ITERAÇÃO 


O planejamento de iterações permite estruturar as atividades do dia a dia da equipe. 
Um release pode conter várias iterações (figura 3.1), de forma que as histórias que 
precisam ser entregues no release são incluídas em uma ou mais iterações. Durante 
a iteração as histórias são desenvolvidas e no final se tem um software desenvolvido 
e testado e, ao terminar uma iteração, uma nova iteração é iniciada. 





li 


-iteração 1 | Iteração 2 ( Iteração 3 ) Iteração 4 ) 


aa dá 


Release 1 Release 2 


Figura 3.1: Releases e Iterações 





As iterações geralmente têm periodicidade semanal, porém, tanto o tempo das 
iterações como dos releases podem ser definidos de acordo com a necessidade de 
cada organização. O tamanho ideal para uma iteração é o menor tempo possível que 
seja necessário para que a equipe consiga entregar algo de valor com qualidade para 
o cliente. 

Ao planejar uma nova iteração, é importante ter em mãos o resultado da iteração 
passada, isto é, a soma das estimativas das histórias que foram desenvolvidas. Esse é 
o número de pontos de estimativa que se pode esperar para a próxima iteração. Essa 
soma de pontos é conhecida como velocidade da equipe. Há quem utilize uma média 
das velocidades das iterações passadas para definir quantos pontos de complexidade 
serão inseridos na nova iteração e há quem prefira utilizar apenas a velocidade da 
última iteração. 

Para inserir as histórias na iteração é preciso que elas estejam estimadas em com- 
plexidade e priorizadas segundo o valor de negócio, o que provavelmente já terá sido 
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feito no planejamento de release. Dessa forma, selecionar as histórias para a iteração, 
geralmente, é algo rápido. O cliente verifica história por história, e as inclui na nova 
iteração de acordo com a prioridade. A somatória de pontos das histórias selecio- 
nadas, idealmente, não deve ser maior do que a definida, seja com base na iteração 
passada ou na média das anteriores. 

Depois de selecionadas quais histórias serão implementadas na nova iteração, é 
preciso explicá-las à equipe. Nesse momento é importante que o PO ou pessoas de 
negócio possa estar presentes para que possam esclarecer aos desenvolvedores suas 
dúvidas de negócio, permitindo que ao final da reunião os desenvolvedores estejam 
preparados para implementar estas histórias. 

Se a equipe conseguir entregar todas as histórias antes do fim da iteração, é pre- 
ciso solicitar ao cliente mais histórias. Então, o cliente escolhe quais deverão ser 
adicionadas à iteração considerando o tempo restante e sua prioridade. Na próxima 
iteração o cliente poderá incluir um número maior de pontos, considerando que a 
velocidade da equipe melhorou. Isso geralmente acontece à medida que a equipe vai 
amadurecendo e ganhando mais domínio sobre a tecnologia utilizada no projeto e 
nos conceitos de negócio. 

Um problema muito comum que pode afetar a ordem de desenvolvimento das 
histórias são as dependências técnicas entre elas. É possível que o cliente determine 
que uma história específica tenha prioridade em relação à outra, porém, tecnica- 
mente pode ser mais viável fazer o contrário. Nesses casos é importante que a equipe 
seja sincera com o cliente em relação às dificuldades técnicas e apresente a ele os be- 
nefícios de implementar as histórias na ordem inversa. Entretanto, é sempre reco- 
mendado que a equipe permita que o cliente escolha o que ele quer que seja entregue 
primeiro e se esforce ao máximo para entregar de acordo com a prioridade determi- 
nada por ele. 

Em se falando de XP e Scrum, não é recomendado adicionar novas histórias a 
uma iteração que já tenha sido iniciada. É comum que ao longo de uma iteração o cli- 
ente solicite que alguma nova história seja adicionada com urgência. Atender a este 
tipo de solicitação emergente e não planejada pode impactar negativamente no anda- 
mento do trabalho da equipe e, como mencionado anteriormente, pela mesma razão, 
não é recomendado alterar as histórias de uma iteração em andamento. Se houver 
muitos casos de mudanças de escopo dentro de uma iteração, e isso, realmente, for 
importante para o negócio, talvez seja o caso de avaliar utilizar um método ágil de 
fluxo contínuo ao invés de iterativo, como Kanban, por exemplo. 


Alterar uma iteração em andamento pode significar trabalho perdido, desgaste, 
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perda da concentração e atrasos. No entanto, responder rapidamente às necessi- 
dades de negócio do cliente é um valor ágil e algo que deve ser sempre levado em 
consideração. 

Em casos como este, é possível negociar com o cliente, e depois de conscientizá- 
lo da problemática de alterar iterações em andamento, incluir a história emergente 
com a condição de retirar da iteração outra história com um valor de estimativa de 
esforço igual ou próximo. Deve-se evitar, é claro, retirar histórias que já tenham seu 
desenvolvimento iniciado. 

O cliente, provavelmente, ficará contente por sua solicitação emergente ter sido 
atendida e mais valor ter sido agregado ao seu negócio. Porém, é preciso ter cuidado 
para que essas emergências não se tornem algo constante e prejudicial. Solicitações 
emergentes devem ser esporádicas. É preciso insistir para que o cliente tenha disci- 
plina e respeite as iterações para que as coisas possam caminhar conforme o plane- 
jamento. 

Outros tipos de demandas não planejadas podem surgir ao longo da iteração. 
Um exemplo muito comum são os indesejáveis defeitos. Por maiores que sejam as 
atitudes preventivas da equipe para manter a qualidade do software com testes e in- 
tegração contínua, é comum que defeitos se apresentem aqui ou ali. Nesses casos 
pode ser necessário que a equipe pare o trabalho e tome providências para sanar o 
problema. 

A lógica é simples: se uma determinada funcionalidade já está em produção, 
significa que ela era mais importante do que as outras que ficaram pendentes, por 
isso foi priorizada e desenvolvida antes das outras. Caso um defeito surja e e essa 
pare de funcionar, provavelmente, será mais importante corrigir o defeito, do que 
entregar algo que tinha menos prioridade. 

Vale a pena acompanhar as demandas de trabalho não planejado que surgem 
durante uma iteração. Se for muito frequentes fique atento: algo provavelmente está 
errado ou talvez seja mais interessante avaliar trabalhar com fluxo contínuo em vez 
de iterações. 


3.4 A REUNIÃO DIÁRIA 


Estabelecer uma comunicação eficiente entre os membros da equipe é extremamente 
importante. As reuniões diárias, conhecidas no XP como “Stand Up Mettings” (Reu- 
niões em Pé) e no Scrum como Daily Scrum (Scrum Diário) são práticas muito efi- 
cazes para que todos estejam sempre a par do status atual do projeto. 
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Todos os dias em um horário preestabelecido, geralmente no início do dia, a 
equipe se reúne por mais ou menos 15 minutos para sincronizar o estado do projeto 
e manter todos informados sobre os últimos acontecimentos e como as coisas estão 
ou não evoluindo. 

Através da reunião diária todos os membros da equipe ficam cientes do anda- 
mento do projeto e podem aproveitar a oportunidade para apresentar suas dificul- 
dades e pedir ajuda aos outros membros. 

No Scrum, por exemplo, cada membro do time responde a três perguntas na 
reunião diária: 


1) O que eu fiz desde a última reunião (ontem)? 
2) O que farei até a próxima reunião (até amanhã)? 


3) Que problemas estão me impedindo de progredir? 


Tim Ottinger, sugere outras 4 perguntas que têm um foco maior em entrega, 
aprendizagem e colaboração [44]: 


e Que histórias você ajudou a terminar desde a última reunião diária? 
e Que história você ajudará a terminar hoje? 
* Como o resto do time pode a ajudar a empurrar uma história para “pronto”. 


e O que você aprendeu de novo? 


Um fator importante que deve ser considerado para uma boa comunicação é o 
número de integrantes da equipe: quanto mais pessoas, mais difícil se torna a co- 
municação. Por isso, equipes ágeis geralmente são compostas por um número de 
membros que varia de cinco a nove pessoas. No capítulo 6 abordaremos com mais 
profundidade algumas boas práticas para formação de equipes. 

É importante que todos tenham oportunidade de falar na reunião diária, nos 
primeiros dias é importante que alguém atue como facilitador (geralmente alguém 
com papel de scrum master) para assegurar que ninguém domine a reunião e fale 
sozinho durante os 15 minutos, ou que alguém deixe de falar. 

Para criar essa disciplina, algumas equipes utilizam alarmes que tocam de 2 em 2 
minutos, por exemplo, para evitar que alguém fale demais. Outras passam um bola 
de mão em mão até que todos a bola volte a pessoa que falou primeiro na reunião. Ao 
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passo que a equipe compreende os benefícios de uma boa reunião diária, esse tipo 
de ferramenta, geralmente, torna-se desnecessária, mas pode ser útil para começar. 
Ken Schwaber, ressalta que é importante que a reunião diária seja realizada em 
um local conhecido por todos [55], e que se deve evitar entrar em discussões que 
fujam do contexto das três perguntas principais como, por exemplo, discutir sobre 
problemas, abordagens de design, as notícias do jornal do dia etc. Se um problema 
que requer discussão for identificado, se necessário, deve-se marcar com os interes- 
sados uma reunião para se discutir após a reunião diária ou em outro momento. 
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PORCOS E GALINHAS 


HEY PIG, | WAS THINKIN' WE 
SHOULD OPEN A RESTAURANT. 


NO THANKS, I'D BE 
COMMITTED, BUT YOU'D ONLY 
BE INVOLVED! 
| | DON'T KNOW. 
WHAT WOULD WE 
CALL IT? 





8y Clark & Vizdos E 2006 implementingscrum.com 


Figura 3.2: Porcos e Galinhas 


A galinha diz para o Porco: 

- Ei Porco, eu estava pensando... Nós deveríamos abrir um restaurante 
juntos. 

O porco responde: 

- Não sei não... Qual seria o nome? 

A galinha responde: 

- Que tal “Ovos com Bacon"? 

O porco responde: 

- Não obrigado. Eu estaria comprometido, e você estaria apenas en- 
volvida. 

No Scrum todos as atividades de gestão do projeto são dividas entre 
os papéis de Scrum Master, Product Owner e Time, essas são as pessoas 
comprometidas como o projeto. O Scrum defende que aqueles que estão 
comprometidos devem ter autonomia para fazer o que for preciso para o 
sucesso do projeto, e que aqueles que estão apenas envolvidos não façam 
intervenções desnecessárias. 

Na reunião diária, por exemplo, no Scrum, as galinhas não podem 
falar, fazer observações, fazer caretas ou intervir, se quiserem participar 
devem ficar na periferia apenas com ouvintes. Isso permite que o time 
fique focado no que é importante sem explicações ou debates desneces- 
sários. 
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3.5 LIMITANDO O TRABALHO EM PROGRESSO 


“Pare de começar e comece a Terminar” 
— Sterling Mortensen 


Discutimos anteriormente que estoque em desenvolvimento de software, é re- 
presentado por trabalho que foi começado, porém ainda não foi terminado e, de 
acordo com o pensamento lean, isso é desperdício, e deve ser eliminado. 

Existe uma relação entre o trabalho em progresso (WIP) e o lead time. É uma 
relação linear proporcional, isso quer dizer que o lead time cresce à medida que o tra- 
balho em progresso cresce, e diminui a media que o trabalho em progresso diminui. 
Essa relação é conhecida na industria como “a lei de little” [50]. 

Definimos o limite do trabalho em progresso no quadro adicionando limites ex- 
plícitos que definem quantos itens podem estar em progresso em cada estado do 
fluxo de trabalho, ou seja, cada coluna do quadro. Veja na figura 3.3: 


PARA FAZER DESENVOLVIMENTO TESTES DEPLOY 





Figura 3.3: Quadro com WIP 


Reduzir o trabalho em progresso, reduz também o lead time, permitindo que se 
entregue com mais frequência. Para isso é importante definir se será ou não permi- 
tido que cada membro trabalhe em mais de uma tarefa ao mesmo tempo. 

Trabalhar paralelamente em duas tarefas pode levar a problemas como interrup- 
ções, falta de foco, desperdício de tempo na mudança de contexto, ou até mesmo na 
mudança de ambiente de desenvolvimento, coisas que levam à perda de produtivi- 
dade. Experimentos empíricos devem ser feitos em cada equipe para verificar o que 
funciona melhor. 
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Os limites podem ser definidos inicialmente com um pouco mais do que a quan- 
tidade de pessoas que trabalha naquela etapa do processo. Numa equipe com dois 
testadores, por exemplo, poder-se-ia iniciar com um limite de 3, e fazer experimentos 
ao longo do tempo para se chegar no limite ideal. 

No quadro da figura 3.3, o limite do desenvolvimento está estourado, e os desen- 
volvedores não podem puxar mais histórias, nem os testadores que estão no limite. 
Nessa situação a equipe toda precisa focar em entregar as histórias que estão mais 
próximas do final do processo antes de poder começar a trabalhar em novas histó- 
rias. 

Sem limite de trabalho em progresso, mais trabalho seria começado, e poderia 
correr o risco de na data de release a equipe não ter terminado ainda uma série de 
histórias e defeitos que mesmo estando em andamento não estariam prontos para 
serem entregues ao cliente. 

Quando uma história ficar pronta no estágio em que se encontra e, esperando 
para ser puxada para o próximo estágio, está em uma fila. As filas devem ser tão 
pequenas quanto possível. Recomenda-se considerar a criação de pequenas filas para 
que absorvam a variação do processo e permitam que fluxo não seja interrompido. 

Muitos processos, se não possuírem filas, poderão fazer com que as pessoas fi- 
quem desocupadas, gerando tempo ocioso, devido a variações no tempo que cada 
item leva para ficar pronto. Novamente, é importante observar seu processo e, em- 
piricamente, optar pela solução que permitir melhor fluidez. 


3.6 ESCREVENDO HISTÓRIAS DE USUÁRIO 


Histórias de usuário são descrições simples e curtas de funcionalidades que deverão 
ser implementadas no software. As Histórias são, geralmente, escritas pelo próprio 
Product Owner, com suas próprias palavras e, então, são registradas em cartões que 
posteriormente são anexadas ao quadro da equipe. 

As histórias contêm apenas uma breve descrição que representa uma necessi- 
dade do cliente, porém, apesar da simplicidade da história, o cliente deve possuir 
o conhecimento necessário para disponibilizar informações de negócio para que a 
equipe possa transformar sua necessidade em software. Por exemplo, imagine uma 
história cuja funcionalidade seja desenvolver um relatório de balanço contábil; será 
necessário que o cliente possua o conhecimento de negócio necessário, isso é, saiba 
o que é um balanço contábil e quais são suas características, para que assim ele possa 
explicar à equipe o que precisa ser feito. 
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Toda história de usuário deve possuir um critério de aceitação, também defi- 
nido pelo cliente, que permite à equipe identificar quando ela está implementada 
por completo e com sucesso. Ao escrever uma história o cliente assume responsabi- 
lidade sobre ela. 

As histórias de usuário têm caráter de negócio, por isso, “instalar o servidor de 
integração contínua” ou “atualizar a versão da biblioteca de injeção de dependências”, 
geralmente, não são exemplos válidos. Podem até ser exemplos de tarefas, mas não 
de histórias de usuários. Veremos a diferença entre histórias e tarefas mais adiante. 

Alguns exemplos de história de usuários válidas em um projeto de desenvolvi- 
mento de um site de relacionamentos podem ser: 


e Um usuario pode publicar suas fotos em seu perfil; 
e Usuários podem criar e participar de comunidades; 


e Comunidades devem possuir moderadores. 


Mike Cohn propôs um formato interessante que é amplamente conhecido e uti- 
lizado no mercado: 


“Eu, como um (papel) quero (funcionalidade) para que (valor de negócio)” 


Se aplicarmos o modelo proposto nas histórias citadas anteriormente, elas fica- 
riam da seguinte forma: 


e Eu como um forista quero publicar minha foto em meu perfil para que os 
outros participantes possam me identificar mais facilmente. 


e Eu como um usuario gostaria de criar uma comunidade para que eu possa 
reunir pessoas com interesses semelhantes aos meus. 


e Eu como um moderador gostaria aprovar ou rejeitar respostas a tópicos do 
forum para evitar postagens inadequadas. 


Investindo em Boas Histórias 


Segundo Mike Cohn, autor do livro: “User Stories Applied”, boas histórias devem 
conter as seis características seguintes: 

1. Histórias devem ser independentes para evitar problemas de planejamento e 
estimativa. Se duas histórias possuírem dependência entre elas, e uma tiver priori- 
dade alta e a outra baixa, provavelmente a história dependente de prioridade baixa 
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precisará ser desenvolvida antes das outras tarefas, assim que chegar a hora da his- 
tória de prioridade alta ser desenvolvida. Nesses casos, pode ser interessante unir 
ambas em uma única história; 

2. Histórias devem ser negociáveis, não devem ser vistas como requisitos que de- 
verão ser implementados a qualquer preço. Lembre-se, histórias são apenas curtas 
descrições de funcionalidades que deverão ser analisadas e discutidas com o cliente 
no momento em que sua prioridade for atingida, ou seja, no momento em que a his- 
tória fizer parte de uma iteração. É importante que a história seja detalhada apenas 
quando o momento de seu desenvolvimento estiver próximo, isto é, quando chegar 
o momento de a história entrar na iteração corrente. Quanto mais cedo ela for ana- 
lisada e detalhada, maiores serão as chances de haver retrabalho e até mesmo perda 
de tempo e energia, considerando que o cliente aprende e muda de ideia à medida 
que as iterações vão sendo concluídas. 

Para ilustrar melhor este exemplo, imagine uma história que tenha como obje- 
tivo a criação de um relatório de apuração de impostos. Imagine que, segundo sua 
prioridade, ela será implementada somente daqui a seis meses, mas que ainda as- 
sim, inicia-se um trabalho de análise e discussão sobre ela. Se o governo realizar 
alguma mudança no plano tributário, você provavelmente terá desperdiçado tempo 
e dinheiro! 

3. Histórias devem agregar valor aos clientes. Como mencionado anteriormente, 
histórias devem descrever funcionalidades que de alguma forma oferecerão ao cli- 
ente retorno ao seu investimento. Por essa razão, histórias de caráter técnico não 
são aconselháveis, por exemplo, “atualizar o Spring Framework para versão 2.5” não 
agrega valor de negócio ao software, pelo menos não diretamente, isso não significa 
que você não possa fazê-lo, mas é aconselhável que exista uma história escrita pelo 
cliente que a justifique; 

4. Histórias devem ser estimáveis. É importante que os desenvolvedores sejam 
capazes de estimá-las. Para que sejam estimáveis é necessário que os desenvolve- 
dores possuam ou tenham acesso através do cliente ao conhecimento de negócio, 
e possuam também o conhecimento técnico necessário para transformar a história 
em software. Seria inviável pedir a um desenvolvedor que nunca escreveu uma linha 
de código em Java que estime o esforço para desenvolver um pedido de venda em 
um projeto Java EE com EJB 3. O mesmo aconteceria se pedissemos ao desenvolve- 
dor para que estimasse o esforço para criar um relatório de fluxo de caixa, sem antes 
explicar a ele o que é um fluxo de caixa; 


5. Histórias devem ser pequenas. Histórias muito grandes são dificeis de esti- 
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mar, por isso deve-se tomar os devidos cuidados para mantê-las sempre curtas e, 
quando necessário, quebrá-las em histórias menores. Para ilustrar melhor, imagine 
a seguinte história: “Um usuário pode realizar compras na loja virtual” Ela pode 
envolver muitas funcionalidades que estão implícitas, e por isso, pode gerar diferen- 
tes interpretações e levar os desenvolvedores ao erro. Em casos como este, podemos 
quebrar a história grande em outras histórias menores: “Um usuário pode adicionar 
produtos ao seu carrinho de compras”, “Ao finalizar a compra o usuário deve esco- 
lher a forma de pagamento”, “Para compras acima de R$100,00 o frete deverá ser 
gratuito” etc.; 

6. Histórias devem ser testáveis. É preciso ter critérios de aceitação bem defini- 
dos para que um desenvolvedor possa saber quando uma história está ou não con- 
cluída. Uma boa prática ao usar cartões para escrever as histórias é pedir ao cliente 
que escreva alguns critérios de aceitação no verso do cartão. 

Para que a história seja testável, é preciso que o cliente escreva critérios objetivos 
e concretos. Por exemplo, “O relatório deve ser intuitivo” é um exemplo de crité- 
rio difícil testar, porque o conceito de intuitivo é abstrato e subjetivo, pode possuir 
significados diferentes para cada pessoa. Ao invés disso, “o relatório deve possuir 
um rodapé com a soma dos valores” ou “o título das colunas deve se manter fixo ao 
navegar entre os lançamentos” são exemplos de critérios fáceis de testar, bastando 
que o desenvolvedor certifique-se de que eles estão sendo atendidos para saber se a 
história será aceita pelo cliente. 


Essas características formam o acrônimo INVEST: 


* I - Independente 
e N - Negociavel 
e V - Valiosa 


E - Estimavel 


S - Sucinta 


e T - Testavel 


Temas, Epicos, Funcionalidades e Histórias 


É comum que muitos projetos de software, naturalmente, possuam uma estru- 
tura hierárquica de requisitos, de forma que algumas necessidades do usuário de alto 
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nível podem ser derivadas em diversas partes menores que, por sua vez, podem ser 
dividas novamente até uma granularidade que possa ser mais facilmente compreen- 
dida e que possa ser desenvolvida em um determinado espaço de tempo. 

Dean Leffingwell, sugere que a hierarquia de requisitos comece com Temasque 
representam um conjunto de iniciativas que guiam os investimentos em sistemas, 
produtos, serviços e aplicações [37]. Desses temas são derivados os épicos, inicia- 
tivas de desenvolvimento que têm potencial de agregar valor ao tema do qual foi 
derivado. São requisitos em alto nível e não são implementados diretamente, antes, 
são quebrados em funcionalidades, que posteriormente são quebradas em histórias 
de usuário (veja na figura 3.4). 





Temas >> Épicos >> Funcionalidades >> Histórias 





















Figura 3.4: Hierarquia de Requisitos 


Épicos são requisitos grandes que, geralmente, não podem ser implementados 
em uma única iteração e, normalmente, contemplam diversos eventos, fluxos e ce- 
nários. Por questões de organização e priorização, muita vezes, é interessante manter 
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esses itens no backlog, sem detalhar exatamente o que deverá ser feito, e então, so- 
mente quando a prioridade do épico for aumentando e a hora de trazê-lo para o 
planejamento estiver se aproximando, será o momento certo para dividi-lo em his- 
tórias de usuário. 

Para melhor ilustrar imagine um sistema de gestão empresarial. O sistema pode 
ter temas como Comercial, Financeiro e Contábil, por exemplo. 

O tema Financeiro pode ser derivado em Épicos como Cobranças e Pagamentos, 
já o Épico Pagamentos pode ser derivado em funcionalidades como Pagamento por 
Boletos e Pagamentos por Depósitos. 

A Funcionalidade Pagamento por Boleto, poderia ser derivada em diversas his- 
tórias, como, por exemplo, Pagamento de Boletos Vencidos, Pagamento de Boletos 
com Juros etc. 


Dividindo Histórias 

É comum que algumas histórias de usuários sejam grandes demais para serem 
implementas em uma única iteração. Nesses casos, é interessante dividi-las em vá- 
rias histórias menores. É importante, porém, manter o aspecto INVEST. Você pode 


dividir histórias por variações nas regras de negócio, por variações nos dados, por 
diferentes cenários de uso etc. 


Quebrando Histórias em Tarefas 


De um modo geral, histórias requerem certo esforço para serem implementadas. 
Por isso elas são dividas em tarefas, que representam os passos necessários para que 
a funcionalidade da história seja desenvolvida e entregue em funcionamento ao cli- 
ente. É recomendado que as histórias sejam quebradas em tarefas que não precisem 
de mais de um dia de trabalho para serem desenvolvidas. Posteriormente veremos 
como isso acontece e como as atividades técnicas são gerenciadas. 

Apenas depois de ouvir o PO e compreender a história, a equipe a quebra em 
partes menores, chamadas simplesmente de tarefas. Neste momento a presença do 
PO é menos importante, porque as tarefas têm um âmbito mais técnico, e geralmente 
terão descrições como: criar as tabelas no banco de dados, criar objetos de negócio, 
realizar integração através de web services etc. 

Não é preciso entrar em detalhes minuciosos sobre cada tarefa e neste mo- 
mento pode-se tomar algumas decisões de design que a equipe considerar 
importante, como linguagens, frameworks, bibliotecas e padrões a serem 
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utilizados, além de questões que envolvam performance e escalabilidade. Decisões 
que a equipe considerar menos importantes podem ser tomadas mais tarde, apenas 
no momento da implementação. 


3.7 MAPEANDO HISTÓRIAS DE USUÁRIOS 


Mapeamento de histórias é uma técnica que consiste basicamente em decompor ati- 
vidades de usuário de alto nível em um workflow que pode ser decomposto poste- 
riormente em um conjunto de histórias de usuário. A técnica, que foi popularizada 
por Jeff Patton, é centrada na perspectiva do usuário [53]. 


Primeiramente, temos os épicos representando requisitos de alto nível, depois 
temos as funcionalidades, e finalmente as histórias 3.5: 


Mais Prioritário Menos Prioritári 
id | | id | | q di || iii 


Figura 3.5: Mapa de histórias 
























OMBJMOLd SOUS 





< 





Dependendo da abordagem os nomes dos niveis de requisitos podem mudar. Na 
abordagem original de mapeamentos de histórias, Patton usa Atividades, Tarefas e 
Subtarefas em vez de épicos e funcionalidades e histórias. Outras fontes entendem 
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que épicos são maiores que temas, por exemplo, mas isso não importa muito: uma 
vez compreendida a essência da prática, você pode escolher a semântica que for mais 
adequada ao seu contexto. 

Note que tudo está priorizado em dois eixos, tanto da esquerda para a direita, que 
representa a prioridade entre diferentes épicos, e diferentes funcionalidades, quanto 
de baixo para cima que representa a prioridade entre diferentes histórias de usuário. 

Depois de pronto e priorizado, você pode utilizar o mapa para definir releases 
em camadas, ou seja releases que contêm um pouco de cada funcionalidade (veja na 
figura 3.6. 


E) Es 
ME 


RELEASE 2 
RELEASE 3 








Figura 3.6: Releases no Mapa de Historias 


Para ilustrar, imagine, por exemplo, um site de comércio eletrônico que sera 
composto por funcionalidades de carrinho de compra, vitrine eletrônica e Consulta 
de Pedidos. Em vez de entregar uma funcionalidade completa com todas as histórias 
envolvidas, é possível entregar algumas histórias de cada funcionalidade por release. 

Dessa forma, o produto poderia ser lançado com o básico de cada funcionalidade 
e já poderia ser utilizado. À medida que os outros releases forem entrando no ar, as 
funcionalidades seriam aprimoradas com a entrega de outras histórias. 
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RECOMENDAÇÕES 


e Desenvolva o mapa de histórias colaborativamente, convide o PO, 
analistas de negócio, desenvolvedores etc. 


e Mantenha o mapa sempre visível para que o time possa discutir 
frente a ele, e tomar decisões mais facilmente uma vez que o mapa 
dá uma visão melhor do “todo” e sobre como as diferentes funci- 
onalidades e histórias de usuário estão conectadas a objetivos de 
negócio [43]. 











3.8 CONHECENDO OS USUÁRIOS ATRAVÉS DE PERSONAS 


Personas são perfis baseados nos clientes e usuários do produto. A criação de per- 
sonas ajuda a identificar Perfis de Clientes e Usuários importantes para o sucesso 
do produto e a melhorar o entendimento, a comunicação e a tomada de decisão do 
time sobre os diferentes usuários, de forma a otimizar suas funcionalidades para o 
perfil do usuário final, e garantir que as necessidades de diferentes perfis sejam bem 
atendidas pelo produto em desenvolvimento. 


Veja uma exemplo de persona na figura 3.7: 
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Roberto 


Descrição 


Trabalha como 
comprador em um 
supermercado de médio 
porte, tem 35 anos de e é 
formado em 
administração. 


Tem mais de 10 anos de 
experiência e tem 
facilidade com 
informática. 


Atividades 
- Faz Pedidos de 
Compra 
- Altera Preços 
- Inclui e Remove 
Fornecedores 


Objetivos 


- Ampliar Margens 
de Lucro das 
Vendas 
- Evitar Falta de 
Produtos nas 
Gondolas 





Figura 3.7: Persona 
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MODELO PARA CRIAÇÃO DE PERSONAS 


Não há uma forma certa ou errada de se desenvolver personas, mas 
essas são algumas características comuns que podem ajudar o time a 
compreender um perfil de usuário. Você pode escolher algumas dessas 
para começar a desenvolver as personas de seu produto: 


e Nome 

e Papel 

e Valores 

e Objetivos 

e Problemas 

e Necessidades 
e Desejos 

e Expectativas 
e Preferências 
e Padrões de Comportamento 
e Casos de Uso 


e Atividades 











Depois de criadas as personas do produto, é interessante associá-las às histó- 
rias de usuário, para que o time saiba quem é o usuário interessado na história a 
ser desenvolvida. É possível fazer isso tornando a persona explicita na descrição da 
história: 

Como um contador eu gostaria de buscar os últimos lançamentos... 

Como um gerentes de contas eu gostaria de atualizar o saldo... 


Como um consumidor eu gostaria de... 


55 


3.9. Melhorando a Previsibilidade com Estimativas Casa do Código 





3.9 MELHORANDO A PREVISIBILIDADE COM ESTIMATIVAS 


A estimativa permite que a equipe meça a produtividade e saiba quanto tempo será 
necessário para concluir o desenvolvimento das histórias do projeto, além de ajudar 
o cliente a entender qual o custo do desenvolvimento de cada história e qual é a 
média de tempo que será necessário para que a funcionalidade seja desenvolvida e 
entregue. 

Estimativas são complexas e não são precisas. Uma série de fatores devem ser 
levados em consideração, entre eles, a maturidade da equipe em relação ao projeto e 
às tecnologias aplicadas nele. 

É comum que no início do projeto funcionalidades de complexidades semelhan- 
tes levam mais tempo para serem implementadas do que no final do projeto. Isso 
ocorre porque a equipe ganha produtividade à medida que aprende mais sobre o ne- 
gócio e sobre a tecnologia utilizada. Assumindo essa premissa, é possível concluir 
que a estimava de uma determinada história pode mudar ao longo do tempo. 

É importante que todos os membros da equipe participem do processo de esti- 
mar. Quando um desenvolver estima uma história sozinho, ele o faz com base em 
suas experiências pessoais. Quando a estimativa é realizada em equipe, o expertise 
envolvido é muito maior e as chances de obter um resultado mais adequado também. 

Uma das medidas mais comuns de estimativa são horas. A equipe indica quan- 
tas horas serão consumidas para que uma funcionalidade seja implementada. No 
desenvolvimento ágil, é mais comum utilizar pontos para realizar estimativas. 

Pontos podem ter significados diferentes de acordo com cada equipe ou projeto. 
Uma das formas, como recomendado no método XP, é quantificar um ponto como 
sendo um dia ideal de trabalho, ou seja, um dia totalmente dedicado a realizar uma 
tarefa, sem interrupções. Dessa forma, dois pontos seriam dois dias e assim por 
diante. 

Outra forma, recomendada pelo método Scrum, é utilizar pontos relacionados 
ao esforço, em vez de tempo. Dessa forma, toma-se uma funcionalidade simples 
como referência, por exemplo, o desenvolvimento de uma tela de cadastro, e assume- 
se que essa referência vale dois pontos. Ao estimar outra tarefa avalia-se em quantas 
vezes mais fácil ou mais difícil em relação à referência é a história atual. 

Outra técnica para tentar absorver a incerteza e falta de precisão das estimativas 
é a utilização de intervalos, como a sequência de Fibonacci: “o, 1, 2, 3, 5, 8, 13, 21, 
34, 55, 89, 144” ou uma sequência simplificada “o, 1, 2, 3, 5, 8, 13, 20, 40, 100”. Assim, 
utiliza-se apenas os valores dentro da sequência para representar o esforço necessário 
para a implementação da história. 
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No Scrum, utiliza-se o Planning Poker, ou Poker de Planejamento. Nesta téc- 
nica cada membro da equipe recebe um conjunto de cartas com os valores de uma 
sequência, como as descritas anteriormente. Em seguida todas as histórias são anali- 
sadas separadamente, e cada membro da equipe coloca uma carta sobre a mesa com 
o número de pontos que considera que a história consumirá. 

Quando houver grandes diferenças, as pessoas que jogaram as cartas de maior e 
menor valor explicam suas razões para escolher aquele valor e, então, com base nas 
explicações, as cartas são jogadas novamente até que um consenso seja encontrado 
e a estimativa seja definida. 

Na realidade, não importa qual técnica sua equipe utiliza, o importante é que 
todos os membros da equipe participem e que seja definido um valor de esforço 
ou custo para que seja possível medir a velocidade da equipe para fundamentar 


o planejamento de releases e dar uma certa previsibilidade para os interessados 
(stakeholders). 


3.10 DEFININDO ENTREGAS COM O PLANEJAMENTO DE RE- 
LEASES 


O objetivo das reuniões de planejamento de releases é definir quando novos incre- 
mentos do projeto serão, finalmente, instalados em produção. Assim como os outros 
procedimentos, esta reunião também deve possuir uma cadência; geralmente, a cada 
duas semanas ou mensal. 

Todos os interessados do projeto podem participar da reunião. Especialistas de 
integração, especialistas de redes, desenvolvedores, testadores, designers e todos que 
estiverem relacionados ao processo de entrega (deployment) devem estar presentes. 
O importante é que a reunião seja composta pelas pessoas capazes de tomar decisões 
técnicas, de negócio e gerenciais. 

Quando o processo de release é muito complexo, pode ser interessante ter uma 
pessoa responsável por coordená-lo. É comum que um gerente de projetos assuma 
esse papel, liderando a reunião, além de coordenar os releases. 

Durante a reunião de planejamento de releases deve-se deliberar sobre que itens 
irão compor o próximo release. Este é um momento oportuno para se levantar e con- 
siderar os ricos, pensar sobre planos de contingência e treinamentos, analisar quanto 
tempo o processo de deploy deverá levar, quem deverá estar presente no momento 
do deploy e quando ele será realizado. 
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Para que os releases sejam curtos é necessário tentar dividir as histórias das itera- 
ções em grupos que representem o mínimo possível de funcionalidade que agregue 
algum valor. Dessa forma o cliente não precisará esperar muito tempo para receber 
retorno de seu investimento, e receberá esse retorno frequentemente em funcionali- 
dades que seriam adicionadas pouco a pouco ao produto, agregando assim cada vez 
mais valor ao software. 

O planejamento de releases oferece um mapa para alcançar o objetivo do projeto. 
Imagine um projeto de seis meses para um supermercado. Poderíamos dividi-lo em 
seis releases de um mês cada. No primeiro release poderíamos entregar o módulo 
de gerenciamento de preços, no segundo release o módulo de pedido de compra, 
no terceiro os relatórios gerenciais, e assim por diante. Assim, a cada mês o cliente 
poderia resgatar um pouco de seu investimento em forma de software. 

É importante buscar entregar o máximo de valor agregado ao cliente a cada rele- 
ase, mas isso não significa o mesmo que entregar o maior número de funcionalida- 
des. É preciso entender o que agregará mais valor. 

Muitas vezes uma única funcionalidade pode agregar mais valor do que dezenas 
de outras juntas. No Scrum, por exemplo, fala-se do conceito de valor de negócio 
ou business value, que pode ser representado por um intervalo numérico, como por 
exemplo de o a 100. O valor de negócio é definido pelo PO, e é através dele que 
a prioridade das funcionalidades a serem desenvolvidas é determinada. Esse valor 
pode mudar ao longo do tempo, por isso é importante estar preparado para adaptar 
o planejamento. 

Outro fator importante em se tratando de priorização é detalhar e quebrar apenas 
os requisitos de maior importância para que seja mais simples se manter as histórias 
priorizadas e organizadas. Por exemplo, se você está desenvolvendo um sistema fi- 
nanceiro, e sabe que não fará o calculo de financiamento nos próximos 5 releases, é 
melhor manter apenas um épico “Financiamento” do que já quebrar em histórias es- 
pecíficas “Calcular Financiamento com Sistema SAC”, “Calcular Financiamento com 
Sistema Price” etc. 
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MANTENHA O BACKLOG PEQUENO 


Para se ter uma ideia de como a complexidade de priorizar histó- 
rias aumenta à medida que se adiciona histórias no backlog: se você 
tiver 3 estórias no backlog (A, B, C), você pode ter 6 ordens de prio- 
ridade diferentes (A, B, C), (B, A, C), (B, C, A), (A, C, B), (C, A, B) e 
(C, B, A). Agora, se você tiver 5 itens, poderá ter 120 ordenações dife- 
rentes, se tiver 10 itens poderá ter 3.628.800 e se tiver 20 itens poderá 
ter 2.432.902.010.000.000.000 ordenações diferentes. Isso mesmo, é um 
calculo fatorial, como nas corridas de cavalos. 











Um dos principais benefícios dos métodos ágeis e do desenvolvimento em ite- 
rações é a redução do tempo das entregas para o cliente. Durante o planejamento 
de releases é importante procurar potencializar o time-to-market, por isso devemos 
descobrir qual escopo necessário para agregar algum valor ao cliente e, então, definir 
um release para entrega. Quanto menores forem os ciclos de release, mais rápido o 
cliente poderá se beneficiar do produto, e oferecer feedback para que ele possa ser 
melhorado. 

Para traçar um planejamento de releases é preciso estabelecer períodos fixos de 
entrega. Recomenda-se que seja um curto espaço de tempo. Com a visão do produto 
em mente é necessário estabelecer quais são as funcionalidades que podem agregar 
maior valor, ou seja, as que possuem maior valor de negócio e serão incluídas mais 
rapidamente nos releases. 

Tendo em mãos a velocidade do time é possível ter uma ideia de quantas fun- 
cionalidades podem ser incluídas em um determinado período de tempo, e então 
dividir as funcionalidades em releases. 

Não planeje para prazos muito longos. Quanto mais longo o prazo, maior a in- 
certeza. Não é necessário, e nem recomendável, escrever e analisar todas as histórias 
no início do projeto. Da mesma forma que a equipe aprende e aprimora suas téc- 
nicas de desenvolvimento a cada release, o cliente utiliza o software e novas ideias 
surgem, bem como ideias antigas podem ser deixadas de lado. É por isso que não 
é interessante tentar prever futuros muito distantes: quanto mais distante, maior a 
incerteza. 

Uma grande diferença dos métodos ágeis em relação aos tradicionais é que os 


métodos ágeis não tentam impedir o cliente de realizar mudanças no planejamento. 
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Em vez disso, considera-se que o cliente também aprende ao longo do projeto e suas 
mudanças trarão benefício. É claro que deve haver algum tipo de proteção para que 
as mudanças com frequência exagerada não tornem o projeto inviável. Tanto o XP 
como Scrum aconselham que ao menos a iteração atual não seja modificada. 

É importante entender a diferença e a relação entre iteração e release. Os releases 
representam entregas e as iterações representam ciclos que estão contidos dentro 
dos releases. As iterações representam um determinado intervalo de tempo em que 
algumas histórias serão implementadas. 

Nas iterações podem estar contidas diversas atividades como as reuniões de re- 
visão e retrospectivas, discutidas. É possível, por exemplo, definir releases mensais 
com quatro iterações de uma semana cada. Não existe regra quanto à periodicidade 
dos releases, afinal cada projeto tem suas particularidades e um release pode implicar 
em uma série de fatores, como por exemplo, implantação e treinamento. Por isso, o 
número de releases e iterações estipulados devem estar alinhados às necessidades da 
sua organização. 


Ao final do release o software é entregue para o cliente pronto para produção. 


3.11 ROADMAP DO PRODUTO 


O Roadmap é uma ferramenta útil para traçar um plano de alto nível sobre futuros 
releases e marcos importantes do produto que serão alcançados ao longo do tempo. 
O Roadmap oferece visibilidade de que funcionalidades serão entregues pri- 
meiro e quais serão entregues depois e em quais releases, e além disso apresenta 
marcos importantes do produto que está sendo construindo (ver figura 3.8). 





Release 1 Release2 |  Release3 
n ie e RE Sinai > 
Produtos Faturamento integração Tempo 
Ordem de Compra A Relatório de Lucros 
VW 
Marco 1 
Comercial 


Figura 3.8: Roadmap 
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Como desenvolvimento de software é altamente complexo por natureza e difícil 
de se estimar e prever, num contexto ágil, o roadmap é uma ferramenta útil para 
mostrar intenções de release e apresentar marcos do produto, mas não tanto para 
definir prazos exatos de entrega de funcionalidades, justamente porque é natural 
que mudanças no escopo do produto ocorram ao longo do desenvolvimento. Por 
isso usa-se mais como um critério relativo do que absoluto, por exemplo, na figura 
3.8 pode-se ver que a funcionalidade de preço, será lançada depois da de pedido, mas 
se está definindo uma data exata para isso. 

Muitas vezes o roadmap pode ser útil para equipes de Marketing e de Negócio se 
posicionarem em relação a (mais ou menos) quando determinadas funcionalidades 


estarão disponíveis para fins de publicidade, treinamentos etc. 


3.12 MANTENHA AS OPÇÕES ABERTAS 


Um do princípios por detrás de muitas práticas dos métodos ágeis é a “liberdade de 
escolha” [40]. Chris Matts e Olav Maassen chamam-no de Opções Reais (em inglês 
Real Options). 

Apesar de não ser exatamente a mesma coisa do que as opções do mercado fi- 
nanceiro (stock options), há uma relação entre os conceitos. As opções do mercado 
financeiro conferem ao titular o direito (e não obrigação/compromisso) de comprar 
um determinado ativo (ação, título ou bem qualquer) por um valor determinado, 
enquanto o vendedor é obrigado a concluir a transação. 

Quando você compra um ingresso para o cinema, por exemplo, para você é uma 
opção porque mesmo tendo comprado o ingresso você pode ou não ir ver o filme; já 
para o cinema isso é mais um compromisso, porque ele já te vendeu o bilhete e agora 
precisará passar o filme no horário determinado. Vai depender do ponto de vista de 
cada um dos lados da relação. 

Muitas vezes nós vemos e encaramos as coisas como compromissos em situações 
que poderíamos encarar como opções. Opções que podemos ou não exercer. 

O pensamento de opções reais consiste em enxergar e avaliar todas essas opções 
ao seu redor e comprometer apenas de forma deliberada. Caso contrário, sempre 
se deve deixar para assumir o compromisso no último momento possível, ou seja, 
quando você tem as informações que precisa para tomar a decisão de comprometer- 
se de verdade. 

Uma opção é uma escolha, uma decisão de escolher uma estratégia em vez da 
outra, de escolher um caminho em vez do outro, de comprar um produto em vez do 
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outro, de trabalhar em uma funcionalidade em vez de em outra. Cada uma dessas 
escolhas tem um retorno sobre o investimento. O desafio é trabalhar com a opção 
que tiver o melhor retorno sobre o investimento. 

A diferença principal entre compromissos e opções é que podemos mudar de 
escolha de opções sem custo algum, ou com um baixo custo, mas mudar um com- 
promisso, geralmente, gera custos ou problemas caso ele não seja cumprido. Temos 
o custo da opção e o retorno sobre o investimento que cada uma oferecer. 

O mais interessante é que há valor nas opções que conhecemos e naquelas que 
não conhecemos também. Por isso é sempre importante considerar todas as opções 
possíveis e procurar aprender sobre opções até então desconhecidas antes de se com- 
prometer com uma determinada opção. 

Decidir no último momento possível (não confundir com negligenciar) é um 
dos princípios de Lean Software Development, e também é algo que faz parte de uma 
série de práticas utilizadas em equipes ágeis como Refactoring e Design Emergente (o 
design não é definido de antemão mas vai evoluindo ao longo do desenvolvimento), 
Planejamento Iterativo (a equipe se compromete apenas com as histórias de usuário 
de um iteração e o resto do backlog torna-se uma opção para o Product Owner; essas 
histórias podem ou não se tornar uma obrigação se incluídas no planejamento da 
próxima iteração), Incrementos Potencialmente Entregáveis (O PO pode exercer ou 
não a opção de fazer um release do resultado de uma iteração) etc. 

Já com métodos tradicionais, o cliente precisa decidir sobre todo o escopo de an- 
temão, e se precisar de alterações terá custos extras, por isso, é levado a tomar uma 
série de (más) decisões antecipadas, e esse mesmo erro permanece no Big Require- 
ments Up Front e no Big Design Up Front. 

Muitas pessoas preferem estar erradas do que estar em dúvida. Por isso, acabam 
tomando decisões ruins, por serem precipitadas [30]. Opções Reais nos apresentam 
uma melhor forma de lidar com nossas decisões. 

Três regras das Opções Reais: 

1. Opções são valiosas: Opções são valiosas porque podem ser executadas. No 
exemplo do ingresso do cinema, para o comprador é uma opção que está justamente 
na possibilidade de entrar na sessão para ver o filme. O valor está em ter opções em 
poder escolher. 

2. Opções expiram: Opções têm um tempo de vida, no caso do ticket de cinema, 
ele só vale durante o tempo do filme, após a sessão do filme, a opção perde seu valor, 
independente de ser sido exercida ou não. 


3. Nunca se comprometa cedo, a menos que saiba o porquê: Quando você se 
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compromete com uma opção está abrindo mão de todas as outras e do valor que elas 
podem oferecer. Quando nos comprometemos cedo demais, há um grande risco de 
não conhecermos todas as opções ou não escolhermos a melhor. 


Injeção de Funcionalidades 


Muitos projetos começam com uma grande lista de funcionalidades abstratas a 
serem desenvolvidas e, então, o time precisa correr atrás de um valor de negócio 
pouco claro e desconhecido. Ou seja, é como se soubessem que têm que correr, mas 
não soubessem a direção e nem por que estão correndo. 

Quando alguém lhe pede para alterar algo da interface de usuário, por exemplo, 
qual é o valor que está por trás dessa mudança? Reduzir o tempo do Processo? Ga- 
nhar novos Usuários? Reduzir a chance de que um erro aconteça? Quando o cliente 
diz “Preciso que seja incluído o Campo X no Sistema”, você sabe o motivo? Que valor 
está por trás disso? Será que isso realmente vai agregar algum valor? Para quem? De 
que forma? 

Às vezes o PO dá ênfase no “como” em vez de enfatizar “o porquê”. Mas se isso 
for invertido, e o PO trouxer o porquê, junto com o time, podem chegar a um “como” 
muito melhor. 

A Injeção de Funcionalidades é um Processo de Análise de Negócios criado por 
Chris Matts com base na Teoria das Opções Reais para resolver esse problema. O 
processo possui três passos bem simples. 

1. Persiga o Valor de Negócio 

Quando o valor de negócio não está claro, as equipes não podem buscar for- 
mas diferentes e mais eficientes de se conseguir o valor. A funcionalidade pode ser 
entregue, porém de forma distorcida e não levar o valor que era esperado. 

A Injeção de Funcionalidades (em inglês Feature Injection) propõe que tudo co- 
mece com um modelo de entrega de valor [6], como por exemplo: “Nós esperamos 
que o tempo médio de faturamento reduza de 20 minutos para 5 minutos, que o nú- 
mero de colaboradores dedicados ao processo reduza de 100 para 40, e a quantidade 
de emissões incorretas reduza de 900 notas fiscais para 100 notas fiscais” 

Um modelo como esse permite que o time avalie as funcionalidades que estão 
desenvolvendo e se, de fato, poderão ou não contribuir para que o modelo de valor 
seja colocado em prática. Torná-lo explícito ajuda a criar um entendimento com- 
partilhado de onde o valor está vindo. Com um objetivo claro, também fica mais 
fácil para se definir o que entra ou não entra no escopo e qual a prioridade de cada 
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item do backlog. Basta procurar entender em que a funcionalidade contribuirá com 
o modelo de valor. 

2. Injete as Funcionalidades 

Depois de ter o modelo bem definido, é hora de criar uma lista de funcionali- 
dades que deverão ser desenvolvidas para atingir o valor de negócio. O importante 
é que deve haver uma ligação clara e objetiva entre as funcionalidades e valor de 
negócio [6]. 

Muitos Product Owners começam perguntando “o que” nós precisamos, em vez 
perguntar “para que” nós precisamos, e isso acaba levando a uma série de funciona- 
lidades que para nada contribuem. Por isso, com Injeção de Funcionalidades você 
começa de trás para frente, ou seja, em vez de perguntar “o que” eu preciso (as en- 
tradas do sistemas) você pensa em “por que” precisa (nas saídas do sistema). 

É importante lembrar que o valor não está nas funcionalidades em si, mas no 
resultado que o uso delas fornece ao usuário. 

Tradicionalmente, as pessoas de negócio vêm com soluções meio prontas em vez 
de apresentar o valor de negócio que estão buscando. Com Injeção de Funcionali- 
dades o time propõe soluções em cima do valor apresentado. 

De certa forma, a Injeção de Funcionalidades é semelhante a TDD (Desenvol- 
vimento Guiado por Testes), porque em vez de começar por escrever o código da 
funcionalidade, no TDD, você começa fazendo um teste que verifica se o resultado 
está correto e depois faz a implementação da funcionalidade. Com Injeção de Fun- 
cionalidades, você começa com o Output do Sistema (Saídas, Resultado) e depois 
descobre os Inputs (Entradas) de que precisa para conseguir o Output. 

Para dar ainda mais ênfase no valor de negócio, Cris Matts, propõe uma inversão 
no formato tradicional das histórias de usuário de Mike Cohn: 

Como um <papel> 

Eu quero <funcionalidade> 

para que <valor de negócio> 

A injeção de Funcionalidades começa pelo valor de negócio: 

Para que <valor de negócio> 

como um <papel> 


eu quero <funcionalidade> 
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EXEMPLO DE INJEÇÃO DE FUNCIONALIDADE 


Para aumentar o número de visitantes no meu site como um publici- 
tário (e aqui entram as opções) 

Para aumentar o número de visitantes no meu site como um publici- 
tário eu quero integrar nosso site com o Facebook 

Para aumentar o número de visitantes no meu site como um publici- 
tário eu quero publicar notícias diariamente 

Para aumentar o número de visitantes no meu site como um publici- 
tário eu quero otimizar o site para mecanismos de buscas 











Note que o valor permanece, mas a funcionalidade pode mudar. Por isso é im- 
portante que o time foque em obter o valor de negócio e não a funcionalidade. 

3. Encontre Exemplos 

Agora é preciso encontrar as variáveis que podem afetar o resultado, ou seja, 
expandir o escopo e com a Injeção de Funcionalidades. Isso é feito através de exem- 
plos: trabalhar com exemplos é uma ótima forma de verificar se as premissas dos 
requisitos são de fato válidas. 

Comece com os exemplos mais simples, depois parta para os mais específicos e 
complicados. Busque exemplos específicos e não generalizados. 

Procure por cenários, por casos reais. É horas de buscar os “quandos”, os “ses” 
os “naquele caso”, os “em particular” etc. Peça exemplos reais para as pessoas de 
negócio. 

A Injeção de Funcionalidade permite que você não se comprometa cedo demais 
como uma solução ruim que pode nem sequer agregar valor, mas que, em vez disso, 
o valor de negócio seja o foco do processo e que puxe tudo o mais que for preciso 
para que ele possa ser conquistado. 


3.13 E AGORA, O QUE EU FAÇO AMANHÃ? 


Você se responsabiliza ativamente pelo resultado do seu time, ou apenas por suas 
contribuições individuais? Reflita sobre isso. 

A visão do produto que você está ajudando a construir está disseminada entre 
todos os membros da sua equipe? Que tal criar um discurso de elevador para seu 
produto? 
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Quais são os marcos mais importantes do seu produto? Faça um roadmap de seu 
produto e identifique-os. 

Quais os diferentes perfis de usuários que utilizam ou utilizarão o produto que 
você está ajudando a criar? Discuta com sua equipe e crie algumas personas, procure 
associá-las com as funcionalidades que vocês estão desenvolvendo atualmente. 

Qual é a frequência com que vocês entregam software para o cliente? Essa 
frequência poderia ser diminuída de alguma forma? 

No próximo planejamento da sua equipe, proponha fazer um mapeamento das 
histórias de usuário, depois de escrever as histórias e organizá-las verifique se estão 
atendendo os critérios INVEST e discuta sobre isso com a equipe. 

Sua equipe já está utilizando limites de trabalho em progresso (WIP)? Se não, 
que tal conversar com time e definir alguns limites iniciais para identificar gargalos 
e problemas de trabalho parado? 

Seu time está mantendo as opções abertas? No que vocês estão se comprome- 
tendo cedo de demais sem saber o porquê? 

Você e seu time sabem o qual é o valor de negócio que está por trás de cada uma 
das funcionalidades que estão desenvolvendo? Será que vocês podem ajudar o PO a 
encontrar formas mais eficientes e baratas se conquistar o valor de negócio que está 
sendo perseguido? 
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Entregando Valor 


Este é o segundo nivel de fluência ágil, no qual os benefícios predominantes são a 
alta produtividade e a melhoria na qualidade externa do produto. 

É um momento oportuno para investimento nas capacidades técnicas da equipe 
e, por isso, agora serão apresentadas algumas técnicas e práticas de engenharia utili- 
zadas por equipes ágeis. 

Equipes neste nível de fluência têm a habilidade de manter seus produtos sempre 
(ou quase sempre) em um estado de pronto-para-entrega, permitindo assim que o 
produto seja atualizado com a velocidade e frequência que o mercado exige. 

Capacitar uma equipe para alcançar um alto nível de habilidade técnica requer 
tempo, esforço e muita prática. Cursos, treinamentos, contratação de desenvolvedo- 
res experientes para ensinar os menos experientes podem ser importantes para se 
atingir esse objetivo [57]. 

O aprendizado de técnicas mais avançadas e o pagamento da dívida técnica cri- 
ada pela falta de experiência e código legado podem reduzir a produtividade neste 
momento. Mas apesar do alto investimento, uma equipe bem capacitada tecnica- 
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mente poderá criar produtos com menos defeitos, o que resultará em mais tempo 
para produzir funcionalidades que realmente possam agregar valor. 

Algumas práticas predominantes neste estágio são: programação em par, inte- 
gração contínua, propriedade coletiva de código, e desenvolvimento orientado a tes- 
tes (TDD). 


A seguir faremos um rápido estudo sobre cada uma dessas práticas ágeis. 


4.1 TESTES ÁGEIS 


Métodos ágeis defendem a ideia de que é preciso criar software de qualidade desde 
o início, ao invés de assegurar a qualidade apenas no final do processo. 

Novas funcionalidades serão entregues com alta frequência e não se pode permi- 
tir que as alterações realizadas no software para criar as novas funcionalidades façam 
com que funcionalidades já existentes deixem de funcionar. É para prevenir que isso 
aconteça que existem os testes de regressão que podem ser realizados manualmente 
ou automatizados. 

Além disso, deve-se prevenir defeitos a todo o momento, porque quanto antes 
um defeito for detectado, mais rápido e barato será para resolvê-lo. 

O que é mais barato: descobrir que uma alteração em uma parte do software 
criou um defeito em outra através do feedback de um testes de unidade durante o 
desenvolvimento e então resolver o problema na mesma hora, enquanto ainda se 
está com as regras de negócio em mente; ou descobrir posteriormente que o defeito 
existe porque não passou pela qualidade ou, ainda pior, descobrir que o problema 
existe apenas quando o software já estiver em produção? 

A resposta, claro, é muito óbvia: quanto mais cedo você descobrir que o pro- 
blema existe, mais rápido e barato será para resolvê-lo. A mesma ideia é aplicada na 
Toyota para defeitos em carros. 

Ao longo desta seção, estudaremos diversas técnicas e abordagens diferentes para 
testes que, combinadas, podem ser úteis e importantes para o desenvolver software 
com qualidade. 

A pirâmide de testes, criada por Mike Cohn [20] é um modelo interessante que 
além de defender que diferentes tipos de testes podem ser combinados, também su- 
gere uma proporção dentre os diferentes tipos, como pode ser visto na figura 4.1: 
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Testes 
Exploratórios 
Manuais 









Testes 
de Ponta a 
Ponta 


Testes de Integração 
(API/Service) 


Testes de Unidade 


Figura 4.1: Pirâmide de Automação de Testes 


Diferentes tipos de testes têm objetivos distintos e seu custo de automação e 
tempo de execução também diferem. 

Testes de Unidade, geralmente, são os mais rápidos se de automatizar e também 
são rápidos de executar, por isso, eles estão na base da pirâmide e representam a 
maior parte dos testes propostos pelo modelo. 

Em seguida, temos os testes de integração (também chamados de testes de ser- 
viço ou testes de API). Eles são mais completos e, geralmente, combinam diferentes 
componentes que trabalham em conjunto para realizar em um determinado sistema. 
São realizados diretamente na aplicação sem passar pela interface de usuário. 

Em terceiro lugar, e no topo da pirâmide, temos os testes de ponta a ponta (tam- 
bém chamados de interface de usuário, testes de sistema, ou testes de aceitação) que, 
como o nome sugere, testam a aplicação desde a interface do usuário, por isso são 
os mais completos e, geralmente, são também os mais caros de se automatizar, e os 
mais lentos para se executar. 

É importante analisar os custos e benefícios de cada um dos tipos de testes pro- 
postos na pirâmide para se fazer bons investimentos em automação de testes. 


Há também os testes exploratórios, que são executados sempre manualmente 
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por um membro do time, com a finalidade de ir além de onde os testes automati- 
zados puderam chegar. Eles não seguem um script pré-planejado e se beneficiam 
da capacidade de investigação, da observação, da analise e da adaptação do testador. 
Através deles os testadores buscam e encontram riscos que extrapolam o universo 
de riscos que puderam ser previstos de antemão pela equipe. 

Em se falando de prevenção de defeitos de software, TDD (Test-Driven Deve- 
lopment) é uma ótima ferramenta na maioria dos contextos. Essa técnica sugere a 
escrita de testes de unidade antes mesmo de se codificar a funcionalidade a ser tes- 
tada. Com isso, é possível garantir alta cobertura de testes [7] e, consequentemente, 
feedback rápido em caso de alterações que possam gerar efeitos colaterais quebrando 
outras funcionalidades. 

A seguir exploraremos um pouco melhor cada um dos diferentes tipos de tes- 
tes. É importante ter em mente que nenhuma abordagem é melhor do que a outra; 
na verdade, cada um deles é uma boa ferramenta para resolver certos tipos de pro- 
blema e, você, provavelmente, precisará combinar todos para garantir a qualidade 
necessária no produto que está desenvolvendo. 


Testes de Unidade 


Escrever testes de unidade é uma prática essencial para se garantir a qualidade de 
um software. Um desenvolvedor ágil evita ao máximo escrever código sem escrever 
também um teste de unidade para verificar se tudo está funcionando da forma como 
deveria, por isso, no método XP, utiliza-se uma prática conhecida como TDD - Test- 
Driven Development ou Desenvolvimento Guiado por Testes. 

Com TDD os testes de unidade são escritos antes mesmo do que as classes e 
métodos a serem testados, melhorando assim a garantia de que todo o código está 
coberto por testes. É importante ressaltar que o conceito de TDD vai muito além de 
apenas escrever testes de unidade, e apresenta, na verdade, uma forma inovadora de 
se pensar no design de um software. 

É muito raro que um desenvolvedor acredite que possa escrever código que sem- 
pre funcionará na primeira vez. Na verdade, muitos ficam surpreendidos quando 
isso acontece. Por isso, independente de escrever testes antes ou depois, é preciso 
testar para garantir que o software está funcionado da maneira que deveria funcio- 
nar. 

Uma alteração em um determinado trecho de código de uma parte de um sistema 
pode causar um problema em outra parte, e os componentes geralmente contêm de- 
pendências, que quando alteradas podem modificar seus comportamentos de forma 
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inesperada: são os conhecidos efeitos colaterais. 

Além de ajudar na melhoria da qualidade, os testes de unidade podem ajudar 
o desenvolvedor a entender melhor as regras de negócio do sistema, uma vez que, 
provavelmente, haverá um teste para cada regra. Dessa forma, eles poderão ser con- 
siderados também uma “documentação viva” porque além servir como referência 
para compreensão das regras de negócio, servirão também para garantir que essas 
regras estejam implementadas corretamente e que o software esteja se comportando 
da maneira que se espera. 

É importante que os testes sejam fáceis de se executar, porque pouco adiantará 
ter testes de unidade que nunca são executados ou que são executados com uma 


frequência muito baixa. 


Testando antes com Desenvolvimento Guiado por Testes 


Desenvolvimento Guiado por Testes (TDD) é um processo em que o desenvolve- 
dor começa a implementação de uma nova funcionalidade pelo teste e deve, o tempo 
todo, fazer de tudo para que seu código fique simples e com qualidade [7]. 


TDD é realizado através de um ciclo com os seguintes passos: 





Figura 4.2: Ciclo de TDD (Imagem de Maurício Aniche) 


1) Adicione um teste rapidamente. 


2) Execute todos os testes e observe o novo teste falhar. 
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3) Faça uma pequena mudança para fazer o teste passar . 
4) Execute todos os teste e observe que foram bem sucedidos. 


5) Refatore. 


O uso de TDD assegura que todo código adicionado ao repositório seja testado 
e, além disso, dá ênfase em se escrever apenas o código necessário para que os tes- 
tes passem, evitando que o desenvolvedor escreva mais do que é necessário, contri- 
buindo para um código mais simples, enxuto e também mais fácil de se dar manu- 
tenção. 


Testando de Ponta a ponta com testes de Aceitação 


Testes de Unidade não são os únicos tipos de teste que devem ser realizados. 
Existem outros tipos que, unidos aos unitários, poderão trazer uma qualidade ainda 
melhor ao software. É o caso dos testes de aceitação, também conhecidos como testes 
funcionais ou testes de usuário final. 

Testes de aceitação, diferente dos testes de unidade que verificam apenas o com- 
portamento de uma classe ou método, testam o comportamento do sistema de uma 
forma mais ampla. Geralmente, representam o contexto completo de uma história 
de usuário, ou caso de uso. Os testes de aceitação, são baseados em critérios de acei- 
tação relacionados com regras de negócio que podem ser especificadas pelo Product 
Owner. 

É possível realizar testes de aceitação manualmente ou automatizá-los. A reali- 
zação de testes manuais pode reduzir drasticamente a velocidade do time, por isso, 
recomenda-se a automação dos testes. 

Algumas ferramentas como o Selenium, por exemplo, permitem realizar a au- 
tomação de testes de aceitação em aplicações web, gravando ações do usuário no 
navegador para que o cenário possa ser reproduzido e os resultados verificados pos- 
teriormente. 


Vá além de testes exploratórios 


Testes Manuais são testes realizados por pessoas, geralmente, que têm o papel 
de testadores em um time de desenvolvimento de software. Alguns testes manuais 
consistem basicamente na execução de um script escrito de antemão que possui uma 
sequência de passos a serem seguidos e um resultado a ser validado. Esse tipo de teste 
pode ser facilmente automatizados. 
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Há, porém, um segundo tipo de teste que é realizado manualmente, conhecido 
como testes exploratórios. Eles se aproveitam de todos o potencial do testador para 
investigar e descobrir cenários, e possivelmente defeitos ou efeitos colaterais, que 
não haviam sido previstos anteriormente. 

Para este tipo de testes não há um script preestabelecido e o testador vai muito 
além do óbvio criando e adaptando sua abordagem ao longo do processo. 


Lidando com Código Legado sem Cobertura de Testes 


É muito comum que uma equipe que não trabalhava com métodos ágeis e passa 
por uma transição se depare com um projeto para evoluir que não possui testes au- 
tomatizados porque na cultura anterior testar e automatizar não era uma prática dis- 
seminada dentre os membros do time. 

Fazer alterações em um sistema que não possui um bom conjunto de testes auto- 
matizados é muito difícil. O maior risco é que você pode facilmente quebrar alguma 
funcionalidade sem que ninguém perceba. 

Por isso Michael Feathers e muitos outros agilistas consideram que código sem 
cobertura de testes é código legado, não importa se foi escrito oito anos ou oito horas 
atrás [24]. 

Uma das opções para mudar essa cenário é melhorar a cobertura de testes pouco 
a pouco a cada iteração. Para isso, Henrik Kniberg sugere o seguinte processo [35]: 


1) Liste seus casos de testes. 


2) Classifique cada teste por risco, o custo de se testar manualmente e o esforço para 
automatizar o teste (veja na figura 4.3. 


3) Ordene por prioridade. 


4) Automatize alguns testes a cada iteração, começando pelos casos de maior prio- 
ridade. 
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Custo de | Custo de 
Caso de Teste Risco i 


Emitir Nota Fiscal 20 pontos 
Cancelar Nota Fiscal 





| CocasrarPráio — | Médio | horas [á portos 





Figura 4.3: Lista de Casos de Teste 


Uma vez tendo a lista pronta e classificada é possível priorizar e começar pe- 
los testes cuja falta apresenta maior risco, e que possuem maior custo de realização 
manual e menor custo de automação. 

Quando não se tem testes automatizados a única forma de garantir que uma al- 
teração não quebrou uma funcionalidade preexistente é realizando testes manuais. 
Não é incomum que o custo de realizar os testes manualmente seja maior do que o 
custo de automatizar, por isso pode ser interessante estimar e apresentar aos inte- 
ressados no projeto para que possam entender o custo benefício do investimento na 
automação deles. 

Nem sempre temos a oportunidade de trabalhar em novos projetos em que po- 
demos garantir alta cobertura de teste desde o princípio mas isso não é motivo para 
desanimar; pouco a pouco, iteração a iteração é possível mudar a realidade do pro- 
jeto e melhorar a qualidade, aumentando a cobertura de testes. 


4.2 SIMPLIFICANDO O CÓDIGO COM REFATORAÇÃO 


Complicar é fácil. Difícil é simplificar 
— Max Gehringer 


É natural que ao longo do tempo a base de código de um sistema vá se tornando 
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cada vez maior, assim como o número de funcionalidades disponíveis e a complexi- 
dade do código fonte. 

Sem boas práticas para manter o código limpo e organizado, à medida que mais 
código vai sendo acrescentado, mais desorganizado e difícil de se compreender o 
repositório vai se tornando. Isso impacta negativamente na produtividade dos de- 
senvolvedores que encontrarão mais dificuldade em dar manutenção nas funciona- 
lidades existentes e em adicionar novas funcionalidades. 


Qualquer idiota pode escrever código que um computador pode entender. Bons 


programadores escrevem código que seres humanos podem entender. 
— Martin Fowler 


Refatorar é alterar a estrutura do código sem alterar o seu comportamento. É 
uma prática que permite que o desenvolvedor melhore o design do código, tornando- 
o mais limpo e fácil de se compreender. É uma técnica essencial para prevenir que o 
código se deteriore [20]. 

Mas para que o desenvolvedor possa alterar o código com segurança de que o 
comportamento não será alterado, é essencial que o código possua uma boa base de 
testes que atuem como uma rede de segurança prevenindo que o comportamento 
do software perca a consistência. Por isso, escrever testes e refatorar são técnicas 
que, geralmente, são utilizadas em conjunto e é exatamente por isso que ambas são 
utilizadas no desenvolvimento guiado por testes, conforme estudaremos a seguir. 

Um bom design evolui ao longo da vida de um sistema, mas Poppendieck afirma 
que um bom design não acontece por acidente. Por isso, ao encontrar algo errado 
na base do código, é preciso parar de incluir novos comportamentos ao software e 
resolver o problema. 

Para garantir uma boa qualidade de código é preciso refatorar. À medida que 
novos comportamentos são incluídos no software, por consequência aumentando a 
complexidade, existe uma grande tendência de se escrever código duplicado e torná- 
lo mais difícil de compreender e de dar manutenção. 

Por outro lado, é preciso tomar cuidado para não cair em um perfeccionismo 
extremo e gastar tempo tentando aperfeiçoar detalhes sem importância. Para facili- 
tar a identificação do momento correto para realizar a refatoração, Poppendieck cita 
cinco características de um sistema íntegro. Se qualquer uma destas estiver faltando, 
é sinal de que é hora de refatorar. São elas: 


1. Simplicidade: Na maioria das vezes um design simples é o melhor design. 
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Design Patterns, quando bem aplicados, são uma ótima ferramenta para aplicar so- 
luções simples a problemas complexos; 

2. Clareza: O código fonte deve ser facilmente compreendido por todos os mem- 
bros da equipe. Todos os elementos do código devem ser devidamente nomeados 
para que sejam facilmente compreendidos por todos; 

3. Eficácia: Um bom design deve produzir o resultado correto, isto é, deve atingir 
o objetivo pelo qual foi criado; 

4. Sem repetição: O mesmo código não deve existir em dois lugares diferentes. 
Quando uma mudança precisa ser feita em muitos lugares o risco de defeitos cresce 
exponencialmente; 

5. Utilidade: Toda funcionalidade de um sistema precisa ser útil para seus usuá- 
rios. Quando uma funcionalidade deixa de ser necessária, cria-se desperdício em 
mantê-la; em muitos casos é melhor eliminá-la. 


4.3 CÓDIGO LIMPO 


Robert C. Martin, um dos criadores do Manifesto Ágil, conhecido na comunidade 
como Uncle Bob, defende com afinco a ideia de que, ao longo do tempo, a base de 
código de um projeto vai se tornando mais bagunçada, e difícil de se entender, im- 
pactando fortemente na produtividade da equipe, que tende a zero, ou seja, a ponto 
de em um determinado momento a equipe não conseguir mais evoluir e incluir no- 
vas funcionalidades no software [41]. 

De fato, muitos softwares, chegam a um tal ponto que precisam ser reescritos do 
zero para que possam continuar a ser evoluídos. 


Algumas características de código limpo são: 


* Elegante, fácil de se compreender, e agradável de se ler. 


Simples e direto. 

e Segue princípios de programação. 
e Sem duplicidade. 

e Bem testado. 


* Parâmetros, Métodos, Funções, Classes e Variáveis possuem nomes significa- 
tivos. 
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e Código é autoexplicativo (sem necessidade de comentários para compreender 
o código). 


e Código bem formatado (é possível ler o código sem precisar utilizar a barra 
de rolagem). 


e Métodos e Classes devem ter uma única responsabilidade (princípio da res- 
ponsabilidade única). 


Trabalhar para manter o código sempre limpo é, além de uma atitude profissional 
do desenvolvedor, muito eficiente em termos de custos para a organização, uma vez 
que a mantenabilidade do software será sustentável a médio e longo prazo. 

Para Uncle Bob, desenvolvedores profissionais escrevem código como profissio- 
nais, e código escrito por profissionais é código limpo! 


4.4 PROPRIEDADE COLETIVA DO CÓDIGO 


A Propriedade Coletiva do Código é uma das práticas de XP e consiste na ideia de 
que o time é responsável por todo o repositório de código em vez de os indivíduos 
serem responsáveis apenas pelo código que eles mesmos escreveram. 

Essa prática faz com que manter e garantir a qualidade do código seja responsa- 
bilidade de todos os membros do time. Qualquer um pode realizar as alterações que 
forem necessárias em qualquer parte do sistema [66]. 

Nessa abordagem, quando um desenvolvedor precisar alterar determinada parte 
do código, não precisará pedir permissão para o desenvolvedor que o escreveu e terá 
total autonomia de fazer o que precisa ser feito. 

Essa prática funciona muito melhor quando em conjunto com revisões de có- 
digo, programação em par e integração contínua. Além de melhorar a qualidade, 
também ajuda na eliminação de ilhas de conhecimento. 

Você já viu uma situação em que determinada parte de um projeto precisa ser 
alterada mas a única pessoa do time que escreveu, compreende e conhece aquele 
código está de férias? Esta pessoa é um ilha de conhecimento, e essa situação é nociva 
para o projeto, porque se cria uma dependência muito grande em uma única pessoa, 
o que possivelmente também resultará em gargalos e sobrecarga. 

Código Coletivo é uma boa vacina contra ilhas de conhecimento, e reduz o risco 
se alguém, por alguma razão, deixar o projeto. 
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Nessa abordagem de propriedade de código, se um desenvolvedor encontrar um 
código pouco claro, sem testes, ou fora dos padrões e qualidade, não importa quem 
o escreveu, esse código poderá e deverá ser melhorado. 


4.5 LINGUAGEM UBÍQUA 


Desenvolvedor: - “Nós estamos com um problema no NFBusinessDelegate quando 
enviamos o objeto para o Service, parece que a transação não é iniciada e o DAO e, 
então, não funciona bem” 

Cliente: - ? 

Desenvolvedores devem falar a linguagem de negócio [66]. 

Um dos grandes desafios do desenvolvimento de software é, muitas vezes, a co- 
municação entre desenvolvedores que não são experts no domínio (áreas de 
negócio) do software com os experts do negócio. [66]. 

Em seu livro Domain-driven design (DDD), Eric Evans cunhou o termo Lingua- 
gem Ubíqua que diz respeito à criação de uma linguagem comum entre experts no 
negócio e o time de desenvolvimento de software. Dessa forma, essa mesma lingua- 
gem de negócio é utilizada no próprio código fonte do software, na hora dar nomes 
a parâmetros, métodos, variáveis, classes, testes, etc. 

É importante que o time compreenda cada um dos termos utilizados por clien- 
tes. É comum que os experts do negócio tenham seus próprios jargões, assim como 
desenvolvedores e testadores também têm seus próprios. Em um projeto sem uma 
linguagem comum, o tempo todo, desenvolvedores precisam traduzir seus termos 
para o expert de negócio, assim como esse também têm que traduzir seus termos 
para os desenvolvedores, e isso prejudica a comunicação [23]. 

Com uma linguagem comum, tanto a linguagem das discussões quanto a do pla- 
nejamento será a mesma utilizada no código. Se, em um sistema de logística, por 
exemplo, o cliente se refere a “cargas”, os desenvolvedores, no código fonte, utiliza- 
rão, precisamente, o mesmo o termo “cargas”, e não mercadorias, ou produtos, ou 
lote, por exemplo. 

O primeiro passo para melhorar a comunicação é reconhecer a sua fragilidade, 
e a linguagem ubíqua é uma excelente ferramenta para ajudar você e sua equipe a se 
comunicarem melhor com as pessoas de negócio envolvidas em seu projeto. 
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4.6 DESIGN ÁGIL É DESIGN ITERATIVO 


Um dos maiores erros do desenvolvimento em cascata é achar que o conhecimento 
existe apenas na forma de requisitos levantados antes do início da implementação e 
separados do desenvolvimento. 

Em uma perspectiva ágil, o desenvolvimento de software é um processo de cria- 
ção de conhecimento, e que na prática, o design detalhado de um software ocorre so- 
mente na codificação. Um design prematuro, ou seja realizado antes da codificação, 
não pode prever a complexidade encontrada durante a implementação, e tampouco 
pode utilizar-se do feedback que só pode ser recebido ao longo do desenvolvimento. 

O design de um software deve evoluir ao longo de seu desenvolvimento. Tentar 
fixá-lo prematuramente resultará em desperdício. 

Em se tratando de requisitos, deve-se seguir a mesma linha de pensamento, de 
forma que os requisitos devem ser detalhados apenas quando estiverem perto da 
hora de desenvolvê-los. É importante também estar preparado para as prováveis 
mudanças neles, uma vez que o cliente também está aprendendo e evoluindo suas 
ideias a respeito da solução que está sendo desenvolvida. 

As abordagens prematuras de levantamento de requisitos e de design são chama- 
das, respectivamente, de Big Requirements Up Front (BRUP) e Big Design Up Front 
(BDUF), e têm sido amplamente abordadas na comunidade ágil como práticas a se- 
rem evitadas, pois o conhecimento não é gerado por antecipação, mas sim através 
de experimentação, codificação e releases frequentes que permitem receber feedback 
dos clientes. O desenvolvimento de software iterativo e incremental encaixa-se per- 
feitamente nessa linha de pensamento. 
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YAGNI: VOCE NAO VAI PRECISAR DISSO... 


“Não pague o preço da complexidade a menos que você realmente precise” 
— Neal Ford 


O princípio YAGNI (You Ain't Gonna Need It ou Você não vai precisar 
disso) muito disseminado na comunidade ágil, defende a ideia de que 
você deve evitar especulações no desenvolvimento de software [25]. 

Isso ocorre naquelas situações em que se pensa “Eu acho que vamos 
precisar disso no futuro, então, vou aproveitar e já fazer”. Dessa forma, 
adiciona-se complexidade desnecessariamente no projeto, e, quando 
mais complexidade, mais difícil de se alterar torna-se o software. 

Procure fazer apenas aquilo que realmente é preciso agora! 











4.7. DEFININDO O SIGNIFICADO DE PRONTO 


A Definição de Pronto (em inglês Definition of Done, referenciado com o acrônimo 
DoD), é, basicamente, um checklist do que deve ser feito antes que uma história 
possa ser considerada potencialmente entregável. 

Não há um checklist oficial que deva ser usado por todas as equipes ágeis do 
mundo, porque, considerando a complexidade do desenvolvimento de software, 
cada equipe é única e está resolvendo um problema dentro de um contexto único. 
Por isso, cada equipe deverá descobrir o que deve fazer parte de sua definição de 
pronto de acordo com seu contexto ou seja, levando em consideração a natureza do 
produto, a tecnologia que está sendo utilizada, as necessidades dos usuários etc. 


Alguns itens comuns são: 


e Código refatorado. 

e Código dentro dos padrões de codificação. 

e Código revisado ou feito em par. 

e Código integrado no sistema de controle de versão. 


* Documentação de arquitetura atualizada. 
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e Testes de unidade realizados. 


e Testes de aceitação realizados. 


Testes exploratórios realizados. 


Nenhum defeito conhecido pendente. 
e PO aceitou na história. 


e Manual do Usuário atualizado. 


É importante que essa definição seja escrita e que fique disponível e visível para 
todos. Isso evita que, por exemplo, uma história de usuário seja dada como pronta, 
mas a documentação para o usuário final não tenha sido escrita ainda, e que, então, 
esse trabalho pendente seja empurrado de uma iteração para a outra, porém não seja 
considerado nas estimativas fazendo com que um falso senso de baixa produtividade 
permeie o ambiente. 

Além disso, a definição também é importante para que haja um mesmo enten- 
dimento do significado de pronto para todos os membros do time, e para que nada 
de importante seja esquecido ou deixado de lado. 

A mesma ideia pode ser aplicada para além das histórias de usuários: também 
para iterações e releases. Geralmente, entende-se que uma iteração está pronta ao fim 
de um intervalo de tempo predefinido, mas pode ser interessante que determinadas 
atividades sejam realizadas antes de se dar uma iteração como pronta, como por 
exemplo fazer deploy em um servidor de homologação ou algo do tipo. 

A participação do PO, na construção dessa definição é muito importante, uma 
vez que ele conhece melhor do que ninguém as expectativas do cliente. 

A definição de pronto não deve ser estática, ao contrário disso, é natural que, à 
medida que o time for evoluindo e amadurecendo, a definição de pronto seja alterada 
para atender critérios de mais e mais qualidade [59]. 


4.8 INTEGRAÇÃO CONTÍNUA 


É natural que em um projeto de desenvolvimento de software os desenvolvedores 
do time trabalhem em paralelo no desenvolvimento de funcionalidades e correções. 
Muitas vezes, podem acabar por alterar os mesmos arquivos gerando conflitos, ou 
até mesmo, alterar arquivos diferentes, que depois de combinadas as alterações, o 
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software apresente um comportamento inadequado. De qualquer forma, de tempos 
em tempos, as alterações precisarão ser integradas em uma base comum de código. 

O processo de integração, geralmente, é visto por desenvolvedores como algo 
custoso e demorado: as peças funcionam bem quando separadas, porém, para tentar 
uni-las e fazê-las trabalhar em conjunto o cenário se torna mais complicado. 

Manter o código sempre integrado e pronto para ser entregue é um grande de- 
safio, e essa é uma das finalidades da integração contínua. A ideia da integração 
contínua é que todos os desenvolvedores realizem integração, isso é, sincronizem o 
código fonte produzido com o sistema de controle de versão, a maior quantidade de 
vezes possível ao longo do dia. 

É recomendado que a cada integração todos os testes de unidade sejam execu- 
tados para assegurar que o build não seja quebrado e que tudo está funcionando 
corretamente. 

Chamamos de build (construção) o processo de gerar um pacote executável de 
software. Isso inclui a compilação de código fonte e, além disso, pode-se acoplar uma 
série de outros processos para garantir que o pacote está em boas condições, como 
análise estática de código, verificação de padrões de codificação, execução de testes 
automatizados, etc. Alguns exemplos de ferramentas de build são: make, Gradle, 
ant, maven e BuildR. 

Se o software possuir um bom nível de cobertura de testes, e os testes forem 
bem escritos, essa prática pode reduzir consideravelmente o número de defeitos em 
produção e garantir que o código fonte produzido para implementar novas funcio- 
nalidades não fez com que algo deixasse de funcionar como deveria. 

Existem diversas ferramentas, na verdade servidores de integração continua — 
inclusive alguns são de uso livre e open-source — que podem ajudar na integração 
contínua. 

É possível configurar essas ferramentas para que cada vez que algum desenvol- 
vedor enviar algum novo código fonte para o sistema de controle de versão, todos 
os testes sejam executados e o desenvolvedor receba uma notificação caso o build 
tenha sido quebrado porque, por exemplo, algum teste tenha falhado. 

Muitos servidores de integração contínua também possuem extensões que per- 
mitem que sejam gerados relatórios de cobertura de testes, identificação de defeitos 
óbvios no código (através de ferramentas de análise estática), entre outras coisas in- 
teressantes. 

Se você ainda não usa nenhuma ferramenta, eu sugiro que comece verificando o 
Jenkins (jenkins-ci.org) e o CruiseControl (cruisecontrol.sourceforge.net). 
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4.9 PROGRAMAÇÃO EM PAR 


A programação em par é uma técnica na qual dois programadores trabalham em 
um mesmo problema, ao mesmo tempo e em um mesmo computador. Enquanto 
uma pessoa (o condutor) assume o teclado e digita os comandos que farão parte do 
programa, a outra (o navegador) a acompanha fazendo um trabalho de estratégia 
[60]. 

A revisão de código, na programação em par, acontece em tempo real. Enquanto 
um desenvolvedor está codificando, o outro está revisando o código. Pequenos er- 
ros, que poderiam ser extramente difíceis de se corrigir posteriormente, podem ser 
facilmente identificados e corrigidos nesse momento. 

Os antigos já diziam que “duas cabeças são melhores do que uma”, e a programa- 
ção também se beneficia disso. Dois desenvolvedores com um conjunto de conheci- 
mento e experiência diferentes são, em regra geral, capazes de resolver um problema 
de forma muito mais eficiente do que poderiam fazer se estivessem trabalhando so- 
zinhos. É o princípio da sinergia aplicado à programação. 

Em um primeiro olhar, pode-se pensar que a programação em par é uma técnica 
que reduz a produtividade da equipe, e que se ambos os desenvolvedores estivessem 
trabalhando em paralelo resolveriam um determinado problema mais rapidamente 
do que trabalhando juntos. 

A programação em par é a prática de desenvolvimento ágil de software com mais 
estudos científicos realizados na Academia até agora, e alguns desses estudos de- 
monstram que, na prática, a programação em par não apresenta grandes diferenças 
de produtividade [67], e que, em geral, o produto é entregue com menos defeitos e 
com melhor qualidade, isso significa que menos tempo será desperdiçado em corre- 
ções de defeitos e que a futura manutenção do software será mais fácil, ou seja, em 
uma análise de médio prazo, podemos concluir que a programação em par é, de fato, 
eficiente. 

Um dos fatores que apoiam essa alta produtividade é pressão dos pares. Nestes 
tempos de redes sociais, e-mail, SMS, e diversas outras distrações, um desenvolvedor 
pode facilmente perder o foco e se distrair quando trabalha sozinho. 

Trabalhando em par, o desenvolvedor assume um compromisso com seu colega 
reduzindo assim a distração e a perda de foco, e como há um colega acompanhando 
a codificação, há uma preocupação maior em criar soluções com mais qualidade e 
elegância. 
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Programação em Par e Aprendizado 


« Z E . . 
Aprender é a única coisa de que a mente nunca se cansa, nunca tem medo e nunca se 


arrepende” 
— Leonardo da Vinci 


Trabalhando em par, o conhecimento do time será rapidamente disseminado en- 
tre os membros do time ajudando na eliminação de ilhas de conhecimento. Para que 
isso aconteça de forma eficiente, é importante que haja um revezamento constante 
entre os pares, de forma que todos tenham oportunidades de trabalhar com todos. 
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A PIRÂMIDE DOS PARES 


Uma ferramenta interessante para incentivar o revezamento entre os 
pares e tonar visível quem está pareando com quem ao longo de uma 
iteração é a Pirâmide dos Pares ou Pair-amid [44]. 

Trata-se basicamente de uma matriz que cruza todos os membros do 
time, e desconsidera os cruzamentos repetidos e os cruzamentos de in- 
divíduo com ele mesmo, veja na figura 4.4. 








Figura 4.4: Pirâmide dos Pares 


No exemplo acima, podemos ver que, até agora, o Robson e o Luiz 
nunca parearam, e que o Robson pareou 3 vezes com a Carol e 2 vezes 
com a Aline. 

Se a pirâmide dos pares ficar visível no quadro do time, tornar-se- 
á uma ferramenta útil para incentivar a programação em par e o reve- 
zamento dos pares resultando em maior compartilhamento de conheci- 
mento entre os membros do time. 











A programação em par cria um espaço para aprendizado contínuo dentro da 
equipe [60]. O trabalho em par também pode ser mais eficiente para disseminar 
conhecimento do que documentações uma vez que não se limita ao que está escrito 
e porque há troca de conhecimento entre ambas as partes. 

É importante, porém, diferenciar programação e par de mentoria [1], a relação 
da programação não é de estudante e professor, mas em vez disso, é uma relação 
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de duas pessoas trabalhando juntas. Se há uma diferença muito elevada no nível 
de conhecimento de dois profissionais trabalhando em par, provavelmente o que vai 
acontecer é que um deles irá ensinar o outro na maior parte do tempo, criando assim 
uma relação que caracterizaria mais mentoria do que com programação em par. 

A mentoria é também, sem dúvida, uma prática muito válida e importante em 
uma equipe de desenvolvimento de software, mas é importante separar um conceito 
do outro, e estar ciente de que a mentoria, geralmente, não resulta na mesma pro- 
dutividade da programação em par, e que, muitas vezes, é um investimento mais de 
longo prazo comparado com a programação em par. 

Em suma, os principais benéficos da programação são melhor qualidade, equipe 
mais motivada, mais confiança e trabalho em equipe, disseminação de conheci- 


mento, e aprendizado contínuo [33]. 





Miro: SEM PROGRAMAÇÃO EM PAR, NÃO HÁ AGILIDADE 


Martin Fowler, uma das personalidades mais respeitadas no mundo 
do desenvolvimento de software, escreveu um artigo em 2006 levantando 
alguns dos principais enganos sobre programação em par. 

Fowler esclarece em seu artigo que “não é necessário programar em 
par para estar praticando um processo ágil” [29], nem mesmo se pode di- 
zer que para aplicar Extreme Programming você é obrigado a programar 
em par. O máximo que se pode dizer é que alguém que quer aprender 
XP deve tentar programar em par e ver se funciona em seu caso em par- 
ticular . 

A programação em par não é nem mesmo citada no manifesto ágil, 
porém, é uma prática altamente recomendada para que se alcance os 


princípios ágeis. 











4.10 REVISÃO DE CÓDIGO 


A revisão de código consiste em um ou mais desenvolvedores lerem o código fonte 
com o objetivo de assegurar a qualidade do código e aprender no processo. Especi- 
almente na implementação de histórias que não foram desenvolvidas com progra- 
mação em par, recomenda-se, a prática de revisão de código. 

A revisão de código melhora sua qualidade e reduz a taxa de defeitos [31]. As 
revisões são oportunidades não apenas de se prevenir erros no código, mas também 


86 


Casa do Código Capítulo 4. Entregando Valor 





de compartilhar e disseminar o conhecimento entre os integrantes do time. Ao revi- 
sar o código alguém pode descobrir boas práticas que não conhecia, ou, em caso de 
encontrar alguma má pratica, então passa a ser uma boa oportunidade de discutir 
sobre formas melhores de solucionar o problema em questão. 

Para que as revisões de código sejam de fato construtivas para o time, é impor- 
tante manter uma atitude de trabalho em equipe quando um problema for encon- 
trado e evitar encontrar culpados ou debochar daquele que cometeu o erro. 

Em um ambiente ágil, parte-se do princípio de que todos estão fazendo o seu 
melhor, então, se eventualmente um problema for encontrado, procure se certificar 
de que todos saibam como evitar que o problema volte a ocorrer, e siga em frente. 

As revisões de código tanto podem fazer parte da definição de pronto e, conse- 
quentemente, do processo, como podem ser esporádicas, sendo realizadas de tem- 
pos em tempos. Em algumas equipes um desenvolvedor revisa o código de outro, 
em outras equipes, a revisão é coletiva envolvendo várias pessoas. 

Algumas organizações fazem uma mescla entre programação em par e revisão de 
código, de forma que tudo o que não for desenvolvido em pares, é revisado. Não há 
fórmula secreta para isso, é interessante testar diversos métodos e encontrar aquele 
que funciona melhor no contexto de sua equipe. 


4.11 DÍVIDA TÉCNICA 


Imagine que você é um desenvolvedor de software que está trabalhando em um sis- 
tema de transferências bancárias. Você está fazendo uma alteração que, teorica- 
mente, seria muito simples, mas percebe que o design atual do sistema precisaria 
sofrer algumas alterações para que fosse possível criar testes de unidade para a alte- 
ração que está fazendo. 

Você, agora, precisa tomar uma decisão: fazer um trabalho “rápido e sujo” para 
resolver o problema rapidamente, mas deixando o código sem testes, ou refatorar e 
alterar o design para que seja possível escrever testes de unidade. 

Desenvolvedores precisam tomar decisões como essas diariamente e, a cada “tra- 
balho rápido e sujo” que fazem, aumentam a dívida técnica do projeto. 

Dívida técnica é uma metáfora criada por Ward Cunningham que ilustra as con- 
sequências desses trade-offs. A ideia básica por trás do termo é que diminuir a qua- 
lidade aumenta o tempo de desenvolvimento a longo prazo. 

Para Cunningham, divida técnica inclui coisas que você escolhe não fazer agora, 
mas que impedirá o desenvolvimento futuro se deixado de lado [21]. Isso inclui, 


87 


4.11. Divida Técnica Casa do Código 





protelação de refatoração, mas não inclui protelação de funcionalidade, a não ser em 
casos que a entrega foi “boa o suficiente” porém não satisfaz algum tipo de padrão 
de desenvolvimento. 





DivipA TÉCNICA OU DÉBITO TÉCNICO 


No conteúdo sobre método ágeis da comunidade brasileira, espe- 
cialmente em blogs, encontra-se muito o termo “débito técnico”, mas 
entende-se que “dívida” é uma tradução mais correta para debt . Em in- 
glês a palavra debt quer dizer dívida (um valor que não foi pago e deverá 
ser pago futuramente), já a palavra debit significa débito (um valor que 
foi retirado de uma conta bancária, por exemplo). 











Depois da definição de Cunningham no início dos anos 90, a comunidade con- 
tinuou a evoluir o conceito [53] e, atualmente, diversos “atalhos” tais como design 
ultrapassado, defeitos conhecidos que não foram resolvidos, baixa cobertura de tes- 
tes de unidade, excesso de testes manuais, entre outros, também são considerados 
parte da dívida técnica. 

Se ela for ignorada, em algum momento o código pode se tornar tão confuso e 
caótico que sua manutenção será prejudicada, aumentando o custo de desenvolvi- 
mento e suporte, diminuindo a produtividade do time, aumentando o número de 
defeitos devido à alta complexidade e dificuldade de compreensão do código, e fi- 
nalmente diminuindo a motivação da equipe, devido à baixa produtividade e alto 
número de defeitos. É previsível que, em num cenário como esse, os clientes e usuá- 
rios, provavelmente, também não estarão muitos contentes. 

O valor da metáfora da dívida técnica está em tornar o time consciente desses 
problemas e de como a produtividade pode estar sendo afetada. Se o time fizer um 
acompanhamento da dívida técnica, é possível evitar que ela se torne cada vez maior 
e, em vez disso, trabalhar para pagá-la pouco a pouco. 

É importante que a equipe mantenha um backlog de dívida técnica, ou seja, uma 
lista de tarefas que podem ser realizadas para melhorar o código, e essa lista pode ser 
priorizada pelo time e, então, pode-se negociar com o Product Owner para que pouco 
a pouco, esses itens sejam incluídos nas iterações. 

Poderíamos ter itens como “Refatorar Método de 2000 linhas na Classe de Trans- 
ferência Bancária”, ou “Atualizar Biblioteca POI para Versão mais Recente para evitar 
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Vazamento de Memória”, ou “Aumentar Cobertura de Testes do Módulo de Emprés- 
timos” etc. 

Alguns tipos de dívida técnica podem ser deliberadamente deixados de lado, por 
não haver valor em resolvê-los. Por exemplo, em casos de produtos próximos ao tér- 
mino de seu clico de vida, ou de um protótipo com objetivo único de aprendizagem, 
ou produtos com ciclos de vida muito curtos (como projetos para campanhas de 
marketing pontuais, por exemplo). É importante que o time foque naquilo que de 
fato trará benefícios para a produtividade do time e qualidade do produto. 

E então? Seu time está pronto para pagar suas dívidas? Lembre-se que assim 
como nas dívidas financeiras, quanto mais tempo levamos para pagar, mais difícil, 
porque paga-se com juros. 





NADA DE JANELAS QUEBRADAS 


Pesquisas no campo de criminalidade e decadência urbana, descobri- 
ram que uma janela quebrada pode rapidamente levar um prédio limpo 
e intacto a se tornar um prédio decadente e abandonado [68]. 

A Teoria da Janela Quebrada afirma que uma janela quebrada, se não 
consertada por algum tempo, transmite para as pessoas um senso que 
ninguém se importa com o prédio [61]. Então, de repente, outra janela é 
quebrada, lixo se acumula, paredes são pichadas, em pouco tempo o pré- 
dio fica tão prejudicado que o dono já não consegue mais repará-lo, então 
o que antes era apenas um senso de abandono, agora se torna realidade. 

Da mesma forma, quando um desenvolvedor deixa um código sem 
cobertura testes, por exemplo, o próximo desenvolvedor tem essa sen- 
sação que não houve zelo por aquele código, e cria um novo método, 
deixando-o sem testar também. 

Com o tempo será possível notar uma grande queda na cobertura de 
testes, tanto que talvez se torne muito difícil para a equipe reverter o ce- 
nário. O mesmo poderia valer para código deixado sem refatorar, ou 
qualquer outra má prática de desenvolvimento. 

Quando uma janela é deixada quebrada, outra será quebrada, e outra, 
e outra... Por isso, não deixe janelas quebrada se achar uma, e nunca seja 
o primeiro a quebrar uma janela. 
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4.12 AGILIDADE EXPLÍCITA COM MURAL DE PRÁTICAS 


“yy ; ae As a ae. 
Nós somos aquilo que fazemos com frequência. Excelência, então, não é um ato, mas 


um hábito” 
— Aristóteles 


Desculpe-me, mas eu tenho que dizer: “Não é o quadro na parede que faz da sua 
equipe uma equipe ágil”. 

O filósofo grego Aristóteles que viveu há mais de 300 A.C. já reconhecia que nós 
somos frutos dos nossos hábitos, das nossas ações frequentes e constantes. Nessa 
linha de pensamento, você não pode dizer que é uma pessoa caridosa, só porque 
uma vez na vida fez uma doação para uma causa beneficente, não pode dizer que é 
uma pessoa aventureira se quando tinha 17 anos de idade pulou de bungee jump no 
parque de diversões. 

Você também não pode dizer que sua equipe é ágil só porque 1 dos 25 desenvol- 
vedores do seu time, uma vez, tentou aplicar desenvolvimento guiado por testes em 
seu tempo livre, e nem pode dizer que sua organização tem uma cultura de apren- 
dizagem só porque há um espaço para palestras uma vez no ano. De jeito nenhum. 
Aristóteles sabia bem do que estava falando. 

O ponto é que “nós podemos dizer que somos ágeis porque nós estamos frequen- 
temente utilizando práticas ágeis” e “nós podemos dizer que nossa organização tem 
uma cultura de aprendizagem porque estamos aprendendo algo novo todos os dias”. 


Quanto mais eu treino, mais sorte eu tenho. 
— Tiger Woods 


A pergunta é: quais são as práticas que fazem de nós uma equipe ágil? E uma 
ferramenta muito simples para ajudar as equipes a se fazerem essa pergunta com 
frequência é o mural de práticas, que consiste basicamente em tornar explícitas to- 
das as práticas de uma equipe através de pequenos ícones expostos em uma área do 
quadro da equipe (veja na figura 4.5. 
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MOVIMENTAR RELEASES 
PESSOAS PEQUENOS CODE SPIKES PRIORIZAR 
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Figura 4.5: Mural de Praticas 


Inclua todas as práticas do seu time, aquelas das que vocês se orgulham e das que 
não se orgulham, torne tudo explícito para que possam visualizar e discutir frequen- 
temente se elas ainda fazem sentido e quando novas práticas poderão ser acrescen- 
tadas. 

Você pode inclusive associar métricas a cada uma dessas práticas para assegurar 
que elas realmente fazem parte do dia a dia do time e não estão no mural apenas de 
enfeite. 

Lembre-se, nós somos aquilo que fazemos com frequência. O que você e seu 
time estão fazendo com frequência, que os tornam ágeis? 


4.13 E AGORA, O QUE EU FAÇO AMANHÃ? 


Seu time já possui uma definição de pronto para histórias, iterações e releases expli- 
cita e visível para todos. Ainda não? Que tal reunir o time e o PO para propor e 
discutir uma definição? Se vocês já possuem definições de pronto, faça uma revisão 
e verifique se ela está atualizada e se está, de fato, representando o estado de pronto 
ideal para o contexto da sua equipe. 

Reúna o time e identifique as práticas ágeis que fazem parte do dia a dia do time, 
construa um mural de práticas e torne tudo explícito. Na próxima retrospectiva, 
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discuta com o time as práticas atuais, se todas elas ainda fazem sentido, e que novas 
práticas poderiam ser acrescentadas para benefício do projeto e da equipe. 
Reconheça e Pague suas Dívidas Técnicas: Reúna sua equipe, e faça um levanta- 
mento da dívida técnica do seu projeto atual. Classes difíceis de se compreender ou 
alterar, código sem cobertura de testes, gambiarras deixadas para trás etc. Levante 
tudo que puder, e procure fazer priorizar junto com o time de acordo com o quanto 
cada um dos itens prejudica a performance do time. Leve a lista ao PO, e negocie 
com ele de que forma esses itens podem ser solucionados ao longos das iterações. 
Sua equipe tem uma política para programação em par? Tudo é feito em par? 
Nada é feito par? Define-se o que será ou não feito em par na Reunião Diária? Que 
tal conversar com equipe sobre isso e definir alguma coisa para a próxima iteração? 
Que tal propor uma sessão de revisão de código com alguns membros do seu 
time? Durante a sessão apresente a seu time alguns dos conceitos de Clean Code 
vistos nesse capítulo. 
Quais métodos vocês estão utilizando para guiar o processo de desenvolvimento? 
Será que podem incluir algumas práticas de outros métodos para aprimorar o pro- 


cesso? 
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Otimizando Valor 


Esse é o terceiro nivel de fluência no qual a equipe passa a entregar ainda mais valor 
agregado e torna-se capaz de tomar melhores decisões para os produtos em desen- 
volvimento. 

Nesse momento a equipe compreende muito bem o que o mercado está pedindo, 
assim como quais são as necessidades de negócio, e como satisfazê-las. 

Agora, a equipe, apresenta seus resultados através de métricas concretas de ne- 
gócio como ROI (Retorno sobre o Investimento), Margem de Lucro Líquido por 
Colaborador, Satisfação do Cliente etc [57]. 

Larsey e Shore afirmam que para se atingir esse nível de fluência a equipe pre- 
cisará de membros especializados em negócio trabalhando em tempo integral como 
parte da equipe (analistas de negócio, gerentes de produto, vendedores, publicitários, 
entre outros de acordo com o domínio de negócio do produto em desenvolvimento). 


5.1 DIRECIONANDO A EQUIPE 


“Para quem não sabe para onde vai, qualquer caminho serve” 


5.1. Direcionando a Equipe Casa do Código 





— Lewis Carroll, Alice no Pais das Maravilhas 


Definir a visão, os propósitos, objetivos e metas da organização e do projeto em 
que o time está trabalhando é uma ótima forma de mostrar a todos a direção para 
qual devem juntos levar a organização através do trabalho realizado no dia a dia. 
Tudo isso são ferramentas para unir e direcionar as pessoas com algumas mudanças 
sutis em termos de abrangência e foco. Nós vamos ignorar essas sutilezas e nos referir 
apenas a metas. 

Uma diferença crucial entres metas tradicionais e metas ágeis é que as caracteris- 
ticas e critérios para definição das ágeis não são fixas, mas variáveis de acordo com 
o contexto [8]. 

Dependendo do objetivo final, algumas metas podem ser mais inspiradoras, ou 
memoráveis, ou específicas, ou ambiciosas, enfim, as características da meta não pre- 
cisam atender a um conjunto de critérios como SMART (Específicas, Mensuráveis, 
Atingíveis, Realistas, Tangíveis) por exemplo, para que sejam úteis para guiar o time. 

A Wikimedia, fundação por trás da famosa enciclopédia digital Wikipedia, apre- 
senta sua missão como: “A missão da Fundação Wikimedia é empoderar e engajar 
pessoas pelo mundo para coletar e desenvolver conteúdo educacional sob uma li- 
cença livre ou no domínio público, e para disseminá-lo efetivamente e globalmente” 
[26], já sua visão é “Imagine um mundo onde cada ser humano possa compartilhar 
livremente na soma de todo o conhecimento. Esse é o nosso compromisso."[27]. 

Note que ambas de uma forma ou de outra mostram exatamente o que a Wi- 
kimedia está fazendo, e no que seus colabores devem concentrar seus esforços para 
conquistar. Esse é o ponto. 

Jamais use metas para intimidar as pessoas ou ameaçá-las, em vez disso, para 
ajudá-las a entender o que a organização precisa que façam naquele dado momento, 
e para que todos possam “remar o barco na mesma direção”. 

Não associe metas a recompensas financeiras, pesquisas apontam que isso pode 
destruir a colaboração e tirar o foco das pessoas do que realmente importa [47], é 
importante que a realização da meta seja a própria recompensa para o time. 

É importante que as metas sejam comunicadas e permaneçam sempre explícitas 
e visíveis para o time. De que vale uma meta se as pessoas que precisam realizar o 
trabalho para que elas sejam atingidas não a conheçam? 

Metas são ferramentas, e como qualquer outra ferramenta, podem ser bem ou 
mal utilizadas. Quando bem usadas podem unir e direcionar o time, quando mal 
usadas podem dividir as pessoas, quebrar a colaboração e desmotivar. 

Faça bom uso de metas! 
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5.2 MÉTRICAS ÁGEIS 


“Tudo que pode ser contado não necessariamente conta; Tudo que conta não 


necessariamente pode ser contado” 
— Albert Einstein 


Métricas podem ser úteis para ajudar o time a compreender onde estão, e ajudá- 
los a comparar com o estado em que querem estar. Assim como as metas, as métricas 
também devem estar sempre explícitas e visíveis para o time. 

O Scrum, por exemplo, sugere que as equipes utilizem burndown charts para 
que todos possam ter feedback de como está o andamento da iteração (estado atual) 
em relação ao planejamento (estado desejado). 

Na figura 5.1 podemos ver um exemplo de burndown, em que a equipe não con- 
seguiu entregar tudo o que foi planejado. O eixo vertical representa o total de traba- 
lho pendente, nesse caso pontos de história de usuário (poderia ser qualquer outra 
medida de trabalho de pendente), enquanto o eixo horizontal representa o tempo, 
nesse caso dias da semana (poderia ser qualquer outra medida de tempo como ite- 


rações ou semanas, por exemplo). 


O Ideal O Realizado 


60 pontos 
45 pontos 
30 pontos 


15 pontos 





0 pontos 
Dia | Dia 2 Dia 3 Dia 4 Dia 5 Dia 6 Dia 7 


Figura 5.1: Burndown Chart 


Note que no dia 4 há uma diferença grande entre o ideal e o realizado e, é uma 
boa oportunidade para que o time possa discutir sobre o que está acontecendo e 
tomar alguma ação para eventualmente melhorar e investir no sucesso da iteração, 


enquanto ainda há tempo. 
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No burndown chart, sempre que algum trabalho for concluído, o gráfico cai, 
quando o trabalho é reestimado, o gráfico sobe, quando algum trabalho é acrescen- 
tado, o gráfico sobe, e quando algum trabalho é removido, o gráfico desce [19]. 

Uma alternativa ao burndown chart, é burnup chart, que em vez de descer à 
medida que o trabalho vai sendo concluído, vai subindo. Alguns times preferem usar 
o burnup porque é mais fácil de expressar alterações do escopo, como por exemplo, 
uma melhoria ou defeito urgente que surgiu ao longo de uma iteração, como pode 
ser visto na Figura 5.2. 


O Ideal O Realizado © Escopo 
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Figura 5.2: Burnup Chart 


Equipes que aplicam o método Kanban, geralmente, utilizam um gráfico seme- 
lhante ao burnup chart, porém detalhado por etapa do processo, permitindo visua- 
lizar a variação do trabalho em progresso ao longo do tempo, trata-se do diagrama 
de fluxo cumulativo (em inglês Cumulative Flow Diagram ou CFD), veja na figura 
5.3. 
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Figura 5.3: Cumulative Flow Diagram 


Com o CED, é possível observar exatamente onde o trabalho em progresso está, 
e quais os gargalos. Observe na figura 5.3, que depois da semana 3 a etapa “testando” 
não parou de aumentar de tamanho, diminuindo as entregas (etapa pronto). Isso 
pode ser um sinal que os testes se tornaram um gargalo e que algo precisa ser feito 
para tornar o processo mais eficiente, aumentando o throughput (entregas). 

Na grande maioria das vezes, esse acumulo de trabalho em determinada etapa do 
processo é um sinal de que é necessário trabalhar os limites de trabalho em progresso 
conforme estudamos na seção 3.5. 

Depois de algumas iterações é possível medir também a velocidade do time por 
iteração (total de pontos entregues por iteração) e a velocidade média, veja na figura 
5.4. 
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O Velocidade por Iteração O Velocidade Média 


60 pontos 


45 pontos 


30 pontos 


15 pontos 





0 pontos 
Iteração | Iteração 2 Iteração 3 Iteração 4 


Figura 5.4: Gráfico de Velocidade 


A velocidade, o escopo pendente/entregue e o trabalho em progresso são as mé- 
tricas mais acompanhadas por equipes ágeis, mas não são as únicas. Por isso, agora 
estudaremos os tipos de métricas, e quais outras podem trazer visibilidade e feed- 
back para a equipe e os interessados no projeto. 


Tipos de Métricas 


Jurgen Appelo e Mike Cohn recomendam que se use dois tipos de indicadores 
[8] [20]: Indicadores Indutores e Indicadores de Resultado. 

Indicadores Indutores (leading indicators) ajudam a detectar um aumento na 
probabilidade ou na gravidade de um evento antes que apareçam nos indicadores 
de resultado. 

Quando um indicador indutor muda, significa que você pode estar no caminho 
para atingir um objetivo ou meta. Por exemplo, aumentar a cobertura de testes ou a 
quantidade de testes criados pode indicar mais qualidade no produto. 

Você pode ter diversos objetivos em uma equipe de desenvolvimento de software, 
como por exemplo, aumento na qualidade, aumento na produtividade, produção de 
melhores estimativas, redução do custo do desenvolvimento, maior previsibilidade 
do cronograma, aumento na satisfação do usuário, releases mais frequentes etc. Para 
cada objetivo você deve ter ao menos um indicador indutor e um de resultado. 

Já os Indicadores de Resultado (lagging indicators) ajudam a confirmar que um 
evento pode ocorrer e reagem mais lentamente às mudanças no ambiente do que 
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os indicadores indutores. São métricas que verificam que você atingiu seu objetivo 
depois de ter completado o trabalho. Por exemplo, reduzir o número de defeitos 
reportados por clientes aponta que a qualidade do produto de fato melhorou. 





MEÇA TIMES E NÃO INDIVÍDUOS 


Quando as pessoas acreditam que serão afetadas pelos resultados de 
métricas sobre seus trabalhos individuais, elas rapidamente encontram 
formas de corromper tais métricas [38], além disso, medir indivíduos 
pode destruir a colaboração do time, uma vez que ajudar um outro mem- 
bro do time pode significar melhorar a métrica de desempenho dele e 
prejudicar a sua própria. 

Já quando mede-se o time em vez do indivíduo, já que a colaboração 
tende a melhorar a performance do time como um todo, a colaboração 


entre as pessoas será mais incentivada. 











Esses são alguns dos indicadores mais comum em ambientes ágeis: 


e Velocidade do Time: Quantidade de pontos de história que um time consegue 
entregar em uma determinada iteração. 


e Aceleração: Alteração da velocidade do time, ao longo das iterações. 


* Lead time: O tempo entre o pedido do cliente e a entrega (o início e o fim do 
processo). Ex: 2 dias do backlog (registro do pedido do cliente) à produção 
(entrega do software funcionando). 


e Cycle time (tempo de ciclo): O tempo total entre o início e o fim da produção 
ou da prestação de serviço. Ex: 6 horas por história de usuário do “to do” ao 


“done”. 


e Tempo de Vida: Quantidade de tempo em que uma história de usuário está 
no Backlog. 


e Quantidade de histórias impedidas: Lista de histórias impedidas por falta de 
informações ou recursos. 


e Taxa de Defeitos por história: A quantidade defeitos para cada história de 


usuário. 
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e Saúde do Build: Tempo que o Build está passando em relação ao tempo que 
está quebrado. 


e Valor de Negócio Agregado: Total de valor de negócio das histórias entregues 


na iteração. 


e Horas Trabalhadas: Soma das horas dedicadas ao projeto por todos os mem- 
bros do time. 


e Cobertura de Testes: Percentual de cobertura de testes de unidade. Pode ser 
facilmente obtido por ferramentas de análise de cobertura. 


* Quantidade de Cenários de Teste: Contagem dos cenários de testes disponi- 
veis. 


* Throughput (Produção): Quantidade de histórias entregues em determinado 
período de tempo. 


e Happiness Index da Equipe: Indica a Motivação do Time, é subjetivo, mas 
pode ser muito útil para perceber quando o clima está ruim e tomar alguma 
ação para melhorar. 


* Trabalho em Progresso (WIP): Quantidade de histórias começadas e não en- 
tregues. 


e Lucro: Influencia das entregas no lucro obtido através dos incrementos no 
produto em desenvolvimento. 


Esses são apenas alguns indicadores que podem ou não fazer sentido no seu 
contexto. As possibilidades são infinitas, porém, procure encontrar as métricas que 
mais podem agregar valor ao time, e dê visibilidade a elas para que o time possa 
acompanhá-las e melhorar a cada nova iteração. 


Mas quem é Responsável pela Métricas? 


No método XP há um papel importante, que muitas vezes é esquecido, trata-se 
do tracker . O tracker acompanha a agenda do time, e algumas métricas, sendo a 
mais importante delas a velocidade do time, que é a relação de tempo ideal estimado 
para as tarefas e o tempo gasto na implementação. 

Ele deve manter seus olhos nos dados importantes a serem acompanhados, como 
a variação da velocidade, horas extras trabalhadas, a relação de testes que passaram 
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e que falharam, a quantidade de defeitos, e métricas como lead time e o tempo de 
ciclo, além de métricas mais técnicas voltadas ao código fonte como cobertura de 
testes, métricas de complexidade, coesão e acoplamento. 

Martin Fowler e Kent Beck resumem que o papel do tracker diz respeito a fazer 
perguntas simples que apontem possíveis problemas [28]. 


5.3 APRESENTE O RESULTADO EM REUNIÕES DE DEMONS- 
TRAÇÃO 


A cada novo incremento que é realizado no produto, é interessante reunir todos os 
envolvidos no projeto para uma reunião de demonstração. 

Nessa reunião a equipe apresenta o que há de novo no produto demonstrando as 
novas funcionalidades. No Scrum, essa reunião é chama “Sprint Review Meeting”. 

Nas Reuniões de Demonstração apresentações de Power Point não são recomen- 
dadas [18], em vez disso, apresenta-se o software em funcionamento. Funcionalida- 
des que não estão prontas não devem ser demonstradas. 

Durante a reunião, os interessados no produto podem fazer comentários, ob- 
servações e manifestar desejos de mudanças nas funcionalidades apresentadas, tudo 
isso pode ser anotado e tratado posteriormente pelo Product Owner. 

Para uma iteração de 1 mês, Ken Schwaber recomenda um tempo maximo de 1 
hora de preparação e 4 horas de duração [55]. 

O Product Owner não precisa necessariamente aguardar até a reunião de de- 
monstração para ver o incremento a ser feito no software e dar feedback a equipe. 
Algumas equipes tem a prática de “Just-in-Time Reviews” [46], isso é, assim que a 
história ficar pronta, a equipe se reúne com o Product Owner para uma rápida de- 
monstração. 


5.4 MELHORIA CONTÍNUA COM RETROSPECTIVAS 


Cada equipe é única e possui características diferentes, nenhum processo é perfeito 
e, raramente, cobrirá todas as necessidades de uma equipe ou projeto. Por essa ra- 
zão, é necessário trabalhar continuamente na melhoria e adaptação do processo. As 
reuniões de retrospectiva são uma excelente forma para fazê-lo. 

As retrospectivas são naturais, afinal todo final de ano, você, provavelmente, faz 
a sua lista de desejos para o ano novo e uma reflexão sobre tudo que conquistou no 
ano que está acabando. De forma semelhante, ao final de cada iteração as equipes 
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se reúnem para uma retrospectiva que visa levantar todos os acontecimentos impor- 
tantes da iteração e refletir sobre o que foi bom, o que deve ser mantido e o que pode 
ser melhorado. 

Nessas reuniões todos os membros da equipe têm a oportunidade de falar sobre 
o que está ou não funcionando bem, sugerir novas práticas, tecnologias, e apresen- 
tar outras ideias em geral, dessa forma todos podem contribuir para a melhoria do 
processo. 

Outro ponto muito importante das retrospectivas é o levantamento dos acon- 
tecimentos mais significantes da iteração, quando a equipe apresenta as principais 
lições aprendidas que serão levadas para o futuro. 

As retrospectivas não têm como foco apenas questões voltadas ao lado técnico do 
desenvolvimento de software, mas vão além, e devem tratar também do lado humano 
e do relacionamento entre as pessoas envolvidas no projeto. Isso, segundo Esther 
Derby e Diana Larser, duas das maiores especialistas no assunto, são questões tão 
desafiadoras quanto ou mais desafiadoras do que as questões técnicas [22]. 

Nenhum processo é perfeito! Além disso, sua equipe é única, e provavelmente 
está sempre enfrentando desafios diferentes de todas as outras, por isso, o processo 
deve ser adaptado e melhorado continuamente para atender de forma eficiente as 
necessidades da equipe. É exatamente nisso que as retrospectivas podem ajudar um 
equipe de desenvolvimento de software. 

Nas retrospectivas é possível que a equipe reflita e identifique mudanças e me- 
lhorias que poderão aumentar a qualidade do software e aprimorar seu dia a dia de 
trabalho. 

Retrospectivas são naturais em métodos ágeis que focam em adaptação e res- 
postas rápidas a mudanças, porém, podem também ser realizadas em equipes que 
utilizam métodos tradicionais. 

James Shore e Shane Warden, sugerem que apenas os membros da equipe parti- 
cipem de retrospectivas [66], para que esses possam sentir-se à vontade e que efetiva- 
mente possam falar abertamente de seus problemas do cotidiano. Deve-se entender 
por “equipe” todas as pessoas envolvidas no projeto que são diretamente ligadas ao 
desenvolvimento do software, isso exclui, por exemplo, clientes, investidores e curi- 
osos. 
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NAO SUBESTIME O PODER DA RETROSPECTIVA 


Retrospectivas, infelizmente, costumam ser a primeira prática a ser 
cortada do processo em momentos que a equipe está sob pressão, mas 
ocorre que, geralmente, a retrospectiva é a melhor oportunidade que o 
time tem de entender porque está nessa situação de pressão e o que pode 
fazer para sair dela. 











O Facilitador de Retrospectivas 


Toda reunião de retrospectiva deve ter um facilitador (também chamado de líder 
de retrospectiva). O facilitador deve garantir que todos os participantes mantenham 
o foco nos objetivos da retrospectiva e ajudar a equipe a se organizar para realizar as 
atividades que os direcionem a descobrir o que precisa ser melhorado e o que pode 
ser feito para melhorar. 

Os facilitadores focam na estrutura e no processo da retrospectiva, e devem es- 
tar constantemente atentos às atividades e ao tempo. É importante que o tempo de 
duração da reunião seja bem definido, apresentado a todos, assim como respeitado. 
Ultrapassar o tempo definido pode fazer com que os participantes fiquem dispersos 
e sintam-se desrespeitados, uma vez que podem ter outros compromissos, atividades 
e obrigações que requerem sua atenção após a reunião. Reuniões que não terminam 
no tempo definido tendem a se tornar cansativas e pouco produtivas. 

Os outros participantes da retrospectiva, em contrapartida, devem estar total- 
mente focados no conteúdo, na discussão e na tomada de decisões, completamente 
despreocupados com o processo da retrospectiva, deixando-o a cargo do facilitador. 

O papel de facilitador pode ser rotativo dentre os membros da equipe, de forma 
que a cada iteração possa existir uma pessoa diferente assumindo esse papel. De fato, 
é recomendável que cada reunião de retrospectiva possua um facilitador diferente, de 
modo que todos possam exercitar esse papel e treinar as habilidades por ele exigidas. 

O facilitador deve permanecer neutro em discussões mesmo quando houver for- 
tes opiniões a respeito do tema em discussão. Se ele estiver engajado na discussão, 
provavelmente não conseguirá fazer um bom trabalho na liderança da retrospectiva. 

O facilitador deve evitar que ocorram conversas em paralelo, e deve assegurar 
que todos sejam devidamente ouvidos. Contudo, ele deve ainda cortar as discussões 
quando estiverem propensas a estourar o tempo da reunião ou impedir que todos os 
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tópicos importantes sejam abordados. 

É essencial que todos tenham oportunidade de falar e que os mais faladores não 
dominem a reunião. O facilitador deve estar sempre atento às pessoas que falam 
demais ou de menos e incentivar pessoas com maior dificuldade de expressar seus 
pensamentos em grupo a falarem. 

Outra responsabilidade do facilitador da retrospectiva é lidar com comporta- 
mentos inadequados ao longo da reunião. Larsen e Debby aconselham evitar chamar 
a atenção das pessoas individualmente, buscando sempre chamar atenção do grupo 
enquanto for possível, enfatizando o comportamento e não a pessoa. 

Além disso, deve-se evitar que as pessoas utilizem a retrospectiva para apontar 
culpados, transformando-a em algo conhecido como jogo de culpas, o que geral- 
mente faz com que as pessoas “levem para o lado pessoal”, percam o foco da re- 
trospectiva e criem um clima desagradável e competitivo, impedindo que o grupo 
trabalhe colaborativamente. 

Ao invés de culpar alguém por ter quebrado o build, por exemplo, deve-se pro- 
curar expor problemas por falta de atenção ao enviar o código ao repositório sem 
antes executar os testes de unidade, e ressaltar a importância de manter-se alerta a 
essa prática. Foco está sempre no problema e não na pessoa (ou possíveis culpados). 

Norm Kerth em seu livro “Project Retrospectives” apontou uma frase, a qual 
chamou de primeira diretriz das retrospectivas: 

“Independentemente do que descobrirmos hoje, nós compreendemos e acredi- 
tamos que todos fizeram o melhor trabalho que podiam, dado o que conheciam, suas 
competências e habilidades, os recursos disponíveis, bem como a situação em mãos. 
[32]” 

Kerth recomenda que no inicio das retrospectivas o facilitador leia a primeira 
diretriz para a equipe. Ela é uma ferramenta para trazer consciência para o trabalho 
colaborativo e para a confiança que os membros da equipe devem depositar entre si. 

Dessa forma, é possível evitar problemas como ataque a indivíduos e distribui- 
ção de culpa. É essencial que as pessoas deixem de lado a competição e colaborem 
para alcançar um bom resultado na retrospectiva, podendo estender isso também ao 
trabalho do dia a dia. 

Aprenda sobre a história e o ambiente da sua equipe. É importante analisar a 
história e moral da equipe, especialmente em relação ao projeto atual. 

Estude quais são os artefatos disponíveis e quais podem ser incorporados para 
ajudar, converse com líderes formais e informais. Essa investigação poderá ajudá-lo 
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a fazer as perguntas certas durante a reunião e o ajudarão a prever quais problemas 
devem ser enfrentados. 

Em suma, o facilitador deve guiar a reunião, assegurar que todos os membros 
da equipe estejam compreendendo os objetivos das atividades e que todos tenham 
chance de falar e expor seus pensamentos. 





QUANTO TEMPO DEVE LEVAR UMA REUNIÃO DE RETROSPEC- 
TIVA? 


Não existe uma fórmula para definir este valor. Como costumam di- 
zer os consultores: depende. Você deve levar em consideração alguns 
fatores como o tempo da iteração, o tamanho da equipe, propensão a 
conflitos e controvérsia, e complexidade dos assuntos a serem discuti- 
dos. O método Scrum, por exemplo, sugere duas horas de reunião de 
retrospectiva para um sprint de 30 dias. 











A facilitação e até mesmo a participação em retrospectivas é um processo de 
aprendizado contínuo: quanto mais prática, maior será a eficiência para alcançar 
bons resultados. Você deve avaliar o resultado das retrospectivas através dos bene- 
fícios conquistados, isto é, das melhorias realizadas por meio das ações que foram 
definidas e efetivamente realizadas. 


As 5 etapas das retrospectivas 


Diana e Derby propõem cinco passos básicos para a realização eficiente de uma 
reunião de retrospectiva ágil [22]. Esses passos ajudarão o facilitador a guiar a reu- 
nião e levar os membros da equipe a trazer à tona possíveis itens a serem melhorados 
e ideias para alcançar as melhorias. 


1) Preparação 

2) Apresentação dos Dados 
3) Insights 

4) Decidir o que fazer 


5) Fechamento 
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Abrindo a Retrospectiva 


Antes de tudo é importante preparar as pessoas para reunião para que foquem no 
trabalho que deve ser realizado ao longo da retrospectiva. Crie a atmosfera ideal para 
que as pessoas sintam-se confortáveis em discutir tópicos complexos e estabelecer 
diálogos desafiadores. 

Defina uma meta para a retrospectiva. Uma meta bem clara oferece às pessoas 
um senso de razão pela qual estão investindo seu tempo. Procure escolher uma meta 
abrangente para que a equipe fique livre para utilizar sua criatividade e alcançar in- 
sights. 

Considere o contexto da equipe e descubra metas que a ajudarão. É certo que 
toda equipe tem suas particularidades, diferentes pontos fortes e fracos. No mo- 
mento de elaborar a meta da retrospectiva, procure algo que represente a busca das 
melhorias que podem trazer maior beneficio para sua equipe em particular. 


Apresentando Dados 


Depois da preparação, vem a apresentação dos dados. Ainda que os benefícios 
de reunir informações de uma iteração que tenha durado uma ou poucas semanas 
possa não ser evidente, essa é uma prática muito importante para a retrospectiva. 

Em uma iteração semanal, por exemplo, perder um dia significa perder 20% dos 
acontecimentos. Mesmo que as pessoas estejam presentes, elas não veem tudo o 
que acontece. Além disso, pessoas diferentes veem os mesmos acontecimentos com 
perspectivas diferentes. Portanto, reunir informações faz com que a equipe crie uma 
visão compartilhada de tudo o que aconteceu, expandindo a perspectiva de toda ela. 

É importante apresentar métricas, histórias de usuário concluídas, decisões to- 
madas, resultados de outras reuniões realizadas ao longo da iteração, desafios en- 
frentados, novas tecnologias adotadas e tudo que tiver significado para a equipe. 

Você pode utilizar como métricas o burndown chart, a velocidade da equipe, o 
número de histórias prontas, o número de defeitos resolvidos, a cobertura de testes 
etc. 

Outra técnica interessante para apresentar os acontecimentos da iteração é criar 
uma linha do tempo e permitir que as pessoas enumerem acontecimentos. Isso faz 
com que as pessoas lembrem-se dos eventos relevantes ao projeto, como releases, 
milestones e problemas diversos que podem ser posteriormente analisados. 

Independente da técnica utilizada, a equipe deve descrever os acontecimentos 
e principalmente os problemas que estão enfrentando, isto é, devem refletir e falar 
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sobre o que não está indo bem. Abaixo apresentamos alguns exemplos de problemas 
comuns que são levantados por equipes nessa etapa da retrospectiva: 


e Não estamos fazendo testes de unidade; 


e Temos dúvidas sobre as histórias de usuário e ninguém está disponível para 
nos ajudar. 


e Há muito retrabalho. 
e Falta de conhecimento técnico. 


e Muitos defeitos. 


Gerando Insights 


Depois de analisar os dados é hora de perguntar os porquês, pensar sobre o que 
se pode mudar e identificar o que fazer de forma diferente. 

A equipe deve utilizar os dados reunidos para identificar os pontos fortes e fracos 
da última iteração, e então expor suas ideias para fortalecer os pontos fracos e não 
permitir que os pontos fortes enfraqueçam. 

Insights são grandes ideias que a equipe acredita que, se aplicadas, serão eficien- 
tes na obtenção de melhores resultados. Busque por condições, interações e padrões 
que contribuíram para o sucesso em melhorias anteriores para encontrar novos in- 
sights. 

Esses insights ajudarão a equipe a descobrir formas de trabalhar com maior efici- 
ência, que é o grande objetivo da retrospectiva. Ao identificar problemas, evite sim- 
plesmente aceitar a primeira solução que for proposta. Ela pode de fato ser a mais 
adequada, porém, vale considerar outras possibilidades, analisar causas e efeitos e 
permitir que a equipe colaborativamente alcance a melhor solução. 

Brainstorming é uma técnica interessante para instigar a equipe a ter insights. 
A técnica consiste em dar à equipe um tempo para pensar, expor e construir ideias 
sobre outras ideias anteriormente propostas. 

Depois de levantado um número suficiente de propostas para resolver problemas 
ou alcançar melhorias, a equipe deve definir filtros e aplicá-los para reduzir o número 
de ideias e então levá-las à próxima etapa para efetivamente decidir o que fazer. 

Uma técnica interessante para resolver isso, é a votação por pontos (figura 5.5. 
Imagine que há 20 proposta. Escreva cada uma em um cartão e dê a cada membro 


107 


5.4. Melhoria Continua com Retrospectivas Casa do Código 





da equipe 5 pontos. Então, cada membro pode investir seus pontos em nos cartões. 
Tanto faz se quiser investir os 5 pontos em um único cartão ou 1 ponto em 5 cartões 
diferentes. Os cartões com maior número de pontos serão os escolhidos. 








Enviar exceptions por e- Usar ferramenta de 
mail para os mebros da profiling para descobrir 
equipe pontos de lentidão 





Escolher um responsável 


semanal por olhar o log 
e registrar erros 





Figura 5.5: Votação por Pontos 


Outra ferramenta poderosa para obtenção de insights é a técnica dos 5 porquês. 
Com dados e fatos em mãos, a equipe pode realizar essa atividade para melhor com- 
preender as razões pelas quais determinados eventos ocorreram. 

A técnica consiste em analisar um determinado acontecimento perguntando por 
que ele aconteceu, e para a resposta a essa pergunta questiona-se novamente o seu 
porquê, e assim sucessivamente até alcançar cinco respostas (veja um exemplo na 
figura 5.6. 
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Muitas Reclamações de 
Clientes nessa Semana 
| Depois da ultima 
Release consultas ficaram 
mais pesadas 
| Não soubemos otimizar 
consultas com o novo 
Framework 
Falta de conhecimento 
técnico do framework 
| s Não estudamos o 
framework antes de 


implantá-lo no sistema 


Figura 5.6: Os 5 porquês 


Essa técnica, muito utilizada para resolução de problemas, foi desenvolvida por 
Sakichi Toyoda na Toyota e faz parte de métodos como Lean Manufacturing e Six 
Sigma. Identificando a causa-raiz do problema, deve-se então trabalhar em sua so- 
lução, ou seja, buscar insights. 

Esse exercício pode ser realizado por toda a equipe em um grupo grande, ou 
em pares, que depois apresentam o resultado a todo o grupo para consolidação das 
ideias. 


Definindo as Ações da Retrospectiva 


O quarto passo tem o objetivo de ajudar a equipe a decidir o que deve ser feito. 
Agora que a equipe tem uma lista de potenciais ideias de experiências e melhorias 
a serem realizadas, é preciso selecionar os itens considerados mais importantes (ge- 
ralmente um ou dois por iteração) e planejar o que fazer, ou seja, que ações tomar. É 
neste momento que o foco da reunião é mudado do passado para o futuro, isto é, da 
iteração anterior para a próxima iteração. 

É importante que a equipe esteja comprometida com os itens que foram seleci- 
onados para serem melhorados na iteração. Um exemplo de ação a ser tomada em 
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uma nova iteração é: “Todos os membros da equipe trabalharão em par dois dias por 
semana”, 

Evite a todo custo sair da retrospectiva sem uma lista clara de ações a serem to- 
madas para alcançar melhorias. Mantenha sempre o foco em coisas que efetivamente 
podem ser melhoradas e evite investir muito tempo em questões que não dependem 
da equipe ou não podem ser mudadas, como mau tempo, trânsito etc. 

É importante que a responsabilidade de realizar as ações definidas na retrospec- 
tiva seja compartilhada e dividida por toda a equipe. Não permita que apenas um 
ou poucos membros da equipe constantemente tomem essa responsabilidade para si 
impedindo que outros colaborem. 


Encerrando a Retrospectiva 


Finalmente, no quinto passo, a equipe deve definir como documentar o que foi 
decidido e aprendido na reunião. Para isso, algumas equipes fotografam o que foi 
escrito na lousa, outras elegem um membro da equipe para criar uma pauta, outros 
escrevem todos os itens em cartões e os guardam, isso fica a critério da equipe. 

É importante que as decisões tomadas fiquem disponíveis de alguma forma para 
consulta de todos e utilização em retrospectivas futuras. Algumas equipes mantêm 
todas as melhorias definidas na reunião de retrospectiva em um backlog de melho- 
rias, que é mantido e priorizado pelo próprio time. 
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COMECE COM O FORMATO MAIS SIMPLES 


Tanta informação, etapas, tempo, preparação, técnicas etc. podem 
parecer um pouco demais para quem está começando. Não se intimide 
com isso, comece reunindo o time em frente a um quadro branco ou um 
flip-chart e discuta com o time sobre as seguintes perguntas: 


e O que está indo bem? 


e O que pode ser melhorado? 


No final das contas o que realmente importa é que a reunião tenha 
como resultado ações a serem tomadas pela equipe para que a melho- 
ria contínua seja aplicada, e que na próxima retrospectiva, a equipe seja 
melhor do que era na última. 

A medida que o time for evoluindo na utilização de métodos ágeis, 
procure variar um pouco as técnicas utilizadas para que a reunião não se 
torne previsível e massante. Dinamizar e alterar o formato da retrospec- 
tiva sem dúvida estimulará a criatividade do time para buscar soluções 
para melhorar continuamente. 

Você pode pesquisar por novas técnicas e dinâmicas de grupo para 
utilizar nas retrospectivas nos sites: http://retrospectivewiki.org e http: 
//tastycupcakes.org. 











5.5 ELIMINANDO DESPERDICIOS COM LEAN 


Taiichi Ohno, criador do Toyota Production System (TPS), definiu-o como um “sis- 
tema de gerenciamento para a eliminação absoluta de desperdícios”, e disse que o que 
deve ser feito é uma linha do tempo entre o momento que o cliente faz um pedido 
até o momento em que recebe o produto e paga por ele, ou seja o processo completo. 

Depois de identificar todas as etapas dessa linha do tempo, deve-se reduzi-la, 
removendo tudo o que não agrega valor, ou seja, deve-se eliminar todo o desperdício. 
Em suma, qualquer atividade que consuma tempo ou dinheiro e não agrega valor é 
desperdício. 
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Desperdício com Trabalho Parcialmente Pronto 


Para indústrias em geral, acumular estoque é considerado desperdício. O esto- 
que precisa ser movimentado de um lado para o outro, armazenado, rastreado, pode 
ser perdido, roubado, ficar obsoleto, quebrar etc. É por isso que o ideal é ter o mí- 
nimo de estoque possível. 

Você deve estar se perguntando: qual é a relação de estoque com software? Esto- 
que na perspectiva de software, para Poppendieck, representa trabalho parcialmente 
pronto, trabalho que pode ficar obsoleto, pode ser perdido [48]. 

Trabalho parcialmente pronto pode ser, por exemplo, requisitos especificados 
com excesso de detalhes antes do desenvolvimento ser iniciado. Lembre-se que re- 
quisitos podem mudar e tornar-se obsoletos, ou ainda histórias de usuários desen- 
volvidas aguardando para serem validadas por uma equipe de qualidade, ou aguar- 
dando para passar por um processo de integração. Tudo isso é trabalho parcialmente 
pronto e consequentemente desperdício. 


Desperdício com funcionalidades que não agregam valor 


A maior fonte de desperdício pode ser vista claramente no Chaos Report [3]: 
somente 20% das funcionalidades desenvolvidas em software são efetivamente utili- 
zadas regularmente; os outros 80% são provavelmente funcionalidades superficiais, 
responsáveis pela maior parte do custo de se desenvolver o software - em outras pa- 
lavras, desperdício. Além disso, ainda aumentam significativamente a complexidade 
da base do código e o custo para mantê-lo. 

O custo da complexidade é exponencial, não linear. Quando a base de código 
é muito complexa, a confiança de realizar alterações de forma segura é pequena. 
Consequentemente, equipes inteligentes mantêm seu código fonte simples, claro e 
reduzido. Porém, para que isso aconteça, toda nova funcionalidade deve ter uma 
boa justificativa do ponto de vista do negócio, de forma que seja algo que realmente 
agregue valor. Poppendieck alerta que software é complexo por natureza, e por isso, 
não gerenciar sua complexidade cuidadosamente é uma receita para o fracasso. 


Desperdício com documentação 


Produzir documentos que ninguém lê é desperdício. Documentar é uma ativi- 
dade que consome o tempo das pessoas e aumenta o tempo de desenvolvimento. 

Evite documentações burocráticas que não serão lidas por ninguém e não agre- 
garão valor ao produto, e concentre-se em documentar somente o que for necessário. 
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Cuidado, porém, para não levar essa ideia ao extremo. Não deixe de documentar o 
que for importante. 


Larry Burns [16] dá algumas dicas para evitar desperdícios com documentação: 


e Não produza documentação que não será lida. 


* Evite produzir documentação que não será atualizada (a menos que seja deli- 
beradamente produzida para satisfazer um requisito temporário, como aten- 
der uma licitação, por exemplo). 


e Não documente coisas óbvias, triviais, redundantes ou informações que po- 
dem facilmente ser obtidas em outras fontes. 


e A documentação deve estar disponível e poder ser facilmente acessada pelos 
interessados. 


É importante encontrar um equilíbrio saudável, e discernir entre o que deve e o 
que não deve ser documentado. 


Desperdício por falta de foco 


De acordo com o livro Peopleware, de Tom DeMarco e Timothy Lister, toda 
vez que alguém é interrompido durante a execução de uma tarefa para trabalhar 
em outra, ou ajudar alguém em algum assunto de contexto diferente do que estava 
fazendo, um tempo significativo é gasto para se concentrar na nova tarefa e voltar ao 
estado de produtividade anterior [39]. Logo, quanto mais interrupções houver, maior 
será o desperdício. Por essa mesma razão não é recomendável que um desenvolvedor 
pertença a várias equipes. 

A programação em par é um bom exemplo de técnica que ajuda a evitar inter- 
rupções, uma vez que duas pessoas trabalhando juntas e trocando conhecimentos 
muito provavelmente não precisarão interromper outros membros do time para re- 
solver problemas. 


Desperdício por atrasos 


Uma das maiores fontes de desperdício no desenvolvimento de software são os 
atrasos. Atrasos por aprovação ou revisão de requisitos, atrasos por contratação de 
pessoal, atrasos nos testes, atrasos na entrega etc. 
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Quanto maior o atraso, mais tempo será necessário para que o cliente obtenha 
retorno sobre o investimento realizado no desenvolvimento do software. 

As técnicas estudadas anteriormente para limitar o trabalho em progresso, e en- 
tregas frequentes forçam o processo a ser mais enxuto e fluído reduzindo assim esse 
tipo de desperdício. 


Desperdício por recursos ou pessoas indisponíveis 


Quando o Product Owner não está presente e não há ninguém que o represente, 
e existe alguma dúvida, ponto a ser esclarecido ou decisão a ser tomada, é preciso 
esperar que ele esteja presente para dar continuidade ao desenvolvimento, ou no pior 
dos casos, por falta de informações, o desenvolvedor pode seguir por um caminho 
inadequado que provavelmente resultará em um defeito. 

Por essa razão é muito importante que o Product Owner esteja presente, próximo 
da equipe. 


Desperdício por defeitos 


Defeitos são sem dúvida uma das maiores fontes de desperdício no desenvolvi- 
mento de software, e quanto mais tempo um defeito leva para ser identificado, maior 
será o desperdício gerado. 

Por essa razão, defeitos devem ser identificados e resolvidos o mais rápido pos- 
sível. 

Essas são apenas algumas das muitas fontes de desperdícios que todas as equipes 
de desenvolvimento de software possuem em maior ou menor grau. O exercício 
constante de analisar e questionar o processo é essencial para que eles possam se 
tornar cada vez menores e menos relevantes. 


5.6 E AGORA, O QUE EU FAÇO AMANHÃ? 


Quais métricas vocês utilizam para acompanhar a produtividade e qualidade do tra- 
balho da sua equipe? Revise as métricas apresentadas na seção 5.2 e verifique se 
alguma delas poderia ajudar. 
Que tal utilizar um dos gráficos apresentados (CFD, Burndown ou Burnup) e 
deixá-lo visível para que toda a equipe possa acompanhar o progresso da iteração? 
Quais dos desperdícios apresentados na seção 5.5 você reconhece no seu projeto? 
O que você poderia fazer para ajudar a reduzir ou eliminá-lo? 
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Procure uma técnica de retrospectiva diferente, uma que nunca foi utilizada em 
sua equipe antes, e ofereça-se para ser o facilitador da próxima retrospectiva. 
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Otimizando o Sistema 


Esse é o quarto nivel de fluência, falaremos sobre o alinhamento da organização 
como um todo, os valores ágeis e práticas ágeis, assim como os objetivos da orga- 
nização, e de como a agilidade pode impactar de forma sistemática a performance 
da organização além do time. 

A teoria do pensamento sistêmico nos ensina que um sistema consiste de partes 
interdependentes que interagem entre si por um mesmo propósito. Um sistema não 
é apenas a soma de suas partes, mas também o produto de suas interações. 

As melhores partes não necessariamente fazem o melhor sistema, de forma que 
a habilidade de um sistema de atingir o seu propósito depende de quão bem suas 
partes trabalham juntas e não apenas de como atuam individualmente. 

Em projetos de desenvolvimento de software, é notável que exista uma tendência 
de se medir o progresso do projeto através de três métricas: escopo, prazo e custo. 

A contrassenso, mesmo otimizando cada uma dessas métricas, nem sempre o 
projeto será bem sucedido, pois elas não levam a qualidade e nem mesmo a satisfação 
do cliente em consideração. Para não ser pego de surpresa, Tom e Mary Poppendieck 
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sugerem aplicar uma métrica de mais alto nível, que considere o resultado de forma 
mais ampla: o retorno sobre o investimento. E complementam: “Se você otimizar o 
que realmente importa, os outros números tomarão conta de si mesmos” [48]. Por 
isso devemos dar preferência para métricas globais em vez de métricas locais [8]. 

Para melhor ilustrar esse conceito, imagine que determinada empresa terceiriza 
os testes dos softwares que desenvolve, e que a empresa terceirizada recebe por de- 
feito encontrado no sistema. Espera-se então que todos os defeitos sejam identifica- 
dos pela empresa terceirizada antes que o software entre em produção. Entretanto, 
quando um defeito for encontrado, provavelmente a empresa terceira não irá cola- 
borar devidamente com a equipe que desenvolveu o software para que defeitos de 
mesma natureza não voltem a ocorrer porque não é de seu interesse que a quanti- 
dade de defeitos diminua. 

Se os defeitos forem encontrados e resolvidos antes do software ir para produção, 
então, a métrica deve apresentar um bom resultado e pode-se vir a pensar que as 
coisas estão indo bem, mas na verdade não está se considerando a real causa do 
defeito, e o problema não está sendo resolvido em sua raiz. 

O objetivo é otimizar o processo da cadeia de valor como um todo e não em cada 
etapa do processo isoladamente. 


6.1 A GESTÃO PODE SER ÁGIL? 


“Aqueles que não fazem acontecer não são nem gerentes nem líderes” 
— Johanna Rothman e Esther Derby 


Muitas pessoas acreditam que a gestão não importa, e que bons técnicos vão 
produzir bons resultados, independente da qualidade da gestão. Johanna Rothman 
e Esther Derby discordam disso. Para elas os bons gestores atingem metas e desen- 
volvem pessoas. Elas afirmam ainda acreditarem que muitos gerentes querem ser 
bons gerentes, porém, não sabem como fazer um bom trabalho. 

Se você não está certo de quem faz o papel de gestor da sua organização, pergunte 
sobre quem se responsabiliza pelo treinamento e desenvolvimento da carreira das 
pessoas. Quem dá feedback sobre o trabalho das pessoas? Quem monitora o trabalho 
da equipe de forma sistêmica? Essa pessoa provavelmente assumiu o papel de gestor. 
O ponto é que a gestão está sempre presente, a questão é se o papel de gestor está 
dividido entre todas as pessoas envolvidas ou se está representado por alguém. 

Jurgen Appelo, no Livro Management 3.0, propõe uma nova abordagem para a 
gestão, mais alinhada aos métodos ágeis, e coerente com a teoria da complexidade. 
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“Para todo problema complexo há uma resposta clara, simples e errada”, 
— H.L. Mencken, Jornalista e Escritor (1880-1956) 


O mundo mudou, e muitos dos conceitos que aplicamos em nossa gestão mo- 
derna foram herdados da era industrial e pré-industrial quando lidamos com profis- 
sionais de perfis completamente diferentes de nossos atuais profissionais da era do 
conhecimento. Devemos reinventar a gestão para que possamos endereçar os desa- 
fios que o mundo dos negócios nos oferece nos tempos atuais. 

Muitos métodos e filosofias como Six Sigma, Total Quality e Teoria das Restri- 
ções foram muito importantes para melhorar a gestão de nossas organizações, po- 
rém estes ainda partem do mesmo princípio de que as organizações operam de cima 
para baixo através de uma hierarquia. A gestão 3.0 trás uma abordagem sistêmica 
que trata a organização como sistema vivo que está constantemente em processo de 
aprendizagem e adaptação. 

A grande dificuldade que temos em lidar com sistemas complexos se deve às 
nossas mentes lineares que preferem causalidade à complexidade. Nós procuramos 
propósito e causa em todas as coisas, buscamos por causa e efeito em tudo. Estamos 
acostumados a estudar e aprender de forma linear, a contar histórias, e é dessa forma 
que enxergamos o mundo, como um lugar repleto de eventos fáceis de serem expli- 
cados através de simples efeitos e causas. Gerald Weinberg chamou isso de Falácia 
da Causalidade. 

A gestão ágil tem suas bases na complexidade, por isso, o foco da gestão ágil deve 
estar na adaptabilidade ao invés de previsibilidade, uma vez que se aceita que muitos 
fatores em projetos são imprevisíveis. 

Para entender melhor a gestão 3.0, vamos entender melhor o que é a Gestão 1.0 
ea 2.0, a final de contas, esse 3.0 não poderia ser apenas Marketing. 

Gestão 1.0: Focada em hierarquias, esta versão da gestão ficou mundialmente 
conhecida através do modelo comando-e-controle. Poder na mão de poucos em uma 
estrutura de decisões top-down. Aqui foi criado aquele conhecido jargão “manda 
quem pode, obedece quem tem juízo”. Podemos dizer, sem possibilidade de erro, 
que ainda é o modelo de gestão mais utilizado “na prática”. 

Gestão 2.0: Focada em técnicas, esta versão procura “corrigir” alguns dos “pro- 
blemas” da primeira versão de gestão, mas mantendo a mesma estrutura top-down, o 
que - não surpreendentemente — resolve muito pouco. Poderíamos dizer que é uma 
Gestão 1.0 “turbinada” por Balanced Scorecards, Six Sigma, TQM e outros add-ons. 


Gestão 3.0: Focada na complexidade, esta gestão encara as organizações como 
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redes, e não como hierarquias; e nessas redes as pessoas e seus relacionamentos de- 
vem estar no foco da gestão, mais do que os departamentos e seus lucros. 

A Gestão 3.0 sugere que a gestão trabalhe com seis visões. Não à toa, essas vi- 
sões são representadas por um modelo um pouco diferente dos conhecidos círculos, 
flechas e retângulos de desenhos organizacionais (veja na figura 6.1); algo bem mais 
próximo do que muitas das organizações se parecem: monstros. 


Alinhar Restrições Desenvolver 
Competências 


~ 








Empoderar 
Times Estruturar 


Energizar as 
Pessoas 


Melhorar Tudo 


Figura 6.1: Martie, O Modelo de Gestao 3.0 (Desenho por Jurgen Appelo) 


Energizar pessoas 


“Uma pessoa com paixão é melhor que quarenta pessoas simplesmente interessadas” E 
— .M. Forster - Romancista Inglés 


Pessoas são a parte mais importante de uma empresa, certo? Gerentes devem 
portanto fazer o que for possivel para manté-las ativas, criativas e motivadas. 

A Teoria X da Motivacao nos diz que as pessoas nao gostam de trabalhar, traba- 
lham por necessidade, porque precisam e por isso, precisam da motivação extrínseca 
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para trabalhar, e além disso precisam de controle para garantir que estão de fato re- 
alizando seu trabalho como devem. Por outro lado, a Teoria Y da Motivação, nos 
diz que as pessoas gostam de seu trabalho e que encontram prazer em trabalhar, e 
por isso podem ser motivadas por seus desejos intrínsecos e não somente por algo 
externo. 

A motivação extrínseca, segundo Jurgen, pode ser vista como um fator higiênico, 
porque podemos compará-la a escovar os dentes, ou tomar banho, por exemplo. Não 
é a quantidade vezes que escovamos os dentes que nos torna mais feliz, mas é a falta 
da oportunidade de escovar os dentes que nos faria tristes. 

Pesquisas apontaram que a motivação extrínseca (em geral dinheiro, bônus, prê- 
mios, e recompensas) não é suficiente para manter as pessoas motivadas, é preciso 
entender quais são os desejos e necessidades de cada indivíduo através da abordagem 
da motivação intrínseca para que então, de alguma forma, seja possível alinhar esses 
desejos das pessoas à realidade da organização, encontrar uma intersecção entre os 
propósitos de cada pessoa e o propósito da organização. 

É importante notar que pessoas diferentes são motivadas por desejos intrínsecos 
diferentes, tais como competência, aceitação, curiosidade, honra, idealismo e pro- 
pósito, independência e autonomia, ordem, poder, status social, relacionados sociais 
etc. Por isso os gestores precisam estar atentos e devem dedicar-se a conhecer a cada 
pessoa individualmente, para entender como pode motivá-las. 


Empoderar times 


Times devem se auto-organizar, mas para isso precisam empoderamento, auto- 
rização e confiança da gestão. 

Apesar de os gestores ainda deterem o poder de contratar e demitir pessoas, em 
ambientes de trabalho que em conhecimento é algo crucial, os trabalhadores do co- 
nhecimento possuem os trabalhos geralmente críticos, e nesse cenário o gestor pode 
ser visto como um líder facilitador que empodera os profissionais para que possam 
tomar as decisões necessárias para realizar o trabalho que são bons em realizar. 

Delegar é ato de transferir responsabilidades para outra pessoa, geralmente 
mantendo-se responsável pelo resultado. Empoderar é mais que delegar — ou di- 
zem alguns, delargar —, para empoderar é preciso considerar o desenvolvimento 
das pessoas, assumir riscos, e em muitas organizações é preciso mudar a cultura. A 
teoria da complexidade nos diz que os problemas devem ser resolvidos o mais pró- 
ximo possível do nível em que eles acontecem. 


Empoderar não é algo binário, tratar como dessa forma aliena as outras pessoas 
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que consideram não ter autoridade de se responsabilizar pelos problemas da orga- 


niz 


ações, já que “não é minha responsabilidade”. Devemos escolher o nível certo de 


empoderamento. 


1) 
2) 


3) 


4) 


5) 


6) 


7) 


Contar (Nível 1): Você (o gerente) toma a decisão e anuncia às pessoas. 


Vender (Nível 2): Você toma a decisão mas tenta ganhar o compromisso das pes- 
soas “vendendo” sua ideia para as pessoas. 


Consultar (Nível 3): Você ouve as opiniões das pessoas e depois toma uma deci- 


sao. 


Concordar (Nivel 4): Você convida as pessoas para uma discussão e entra em um 
acordo com elas, chega a um consenso. Neste nível, sua voz é igual a dos outros. 


Aconselhar (Nível 5): Você tenta influenciar as pessoas dizendo a elas sua opinião, 
mas deixa a elas a responsabilidade de tomar uma decisão. 


Questionar (Nível 6): Você permite que as pessoas decidam antes, mas depois 
pede a elas que vendam a decisão a você. 


Delegar (Nível 7): Você permite que as pessoas tomem uma decisão sem qualquer 
nível de envolvimento da sua parte. 


Além de definir os níveis de empoderamento, é importante também deixar ex- 


plícito para que todos saibam “onde podem pisar”. Jurgen Appelo desenvolveu uma 


forma simples e eficiente de tornar a delegação transparente através do Quadro de 


Delegação [12] (veja na figura 6.2. 
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Contratar Tot 
Definir Salários LO) 


Priorizar Projetos 


Comprar Licenças Mary 
Formar Equipes Te 


Definir Tecnologia Te 


Figura 6.2: Quadro da Delegação 


No topo do quadro, temos os 7 niveis de empoderamento, e nas linhas temos 
as areas de delegação-chave (essas áreas vão variar de acordo com o contexto, esse 
é apenas um exemplo). Nas colunas nos temos a definição de quem é responsável 
(representado por uma pessoa, um papel, ou uma equipe). 

Por exemplo, no quadro da figura 6.2, salário está no nível 2 e na responsabili- 
dade de uma pessoa chamada Bill. Isso quer dizer que Bill define os salários mas 
tenta “vender” para o time suas decisões sobre salários. Já o item comprar licen- 
ças está na responsabilidade da Mary no nível 3, isso significa que apesar de ela ser 
responsável por tomar essa decisão, ela precisará pedir a opinião do time antes de 
decidir. Já o item definir tecnologia está na responsabilidade do time no nível 7, o 
que significa que o time tem total autonomia para decidir sobre tecnologia e que não 
há necessidade de consultar a gestão antes de decidir. 

O quadro de autoridade é uma ótima forma para tornar transparente quem pode 
fazer o quê. Identifique quais são as áreas de decisão-chave na sua organização e 
procure definir os níveis de delegação de cada um. Uma vez visível e transparente, 
será mais fácil de questionar e identificar o que pode mudar para melhor. 


Alinhar Restrições 


“O que é medido é gerido” 
— Peter Drucker 
A Gestão 3.0 nos apresenta o empoderamento como um investimento que faze- 


mos nas pessoas. É preciso compreender que será preciso tempo para que as pessoas 
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ganhem experiência e adquiram conhecimento para que possam fazer determinadas 
coisas tão bem quanto quem as delegou é capaz de fazer. 

Alinhar restrições: auto-organização pode não funcionar, para diminuir esta 
possibilidade dê às pessoas um propósito claro e metas compartilhadas. 

A auto-organização pode levar a qualquer resultado, bom ou ruim, faz parte do 
papel do gestor dar às pessoas uma meta compartilhada para que possam se auto- 
organizar, de uma forma que produza valor para a organização. O objetivo desta 
meta compartilhada é dar às pessoas uma direção a seguir. 

Nos últimos anos, temos repetido que nossas metas devem ser SMART (Espe- 
cíficas, Mensuráveis, Atingíveis, Realistas, e Oportunas), porém do ponto de vista 
da complexidade, podemos entender que metas com objetivos específicos possuem 
característica diferente umas das outras. Por exemplo, se a sua meta é aproveitar as 
férias na Noruega, como você vai medir isso? Contará seu número de sorrisos por 
dia? 

Além disso é necessário ter métricas diferentes para os diferentes interessados do 
projeto (equipe, cliente, gerente, comunidade etc.). Os resultados devem ser expli- 
citos e visíveis para que os envolvidos possam entender como estão e aonde devem 
chegar e tomar ações para melhorar. 


Desenvolver competências 


O encontro da preparação com a oportunidade gera o rebento que chamamos sorte. 
— Anthony Robbins 


Times não conseguirão atingir suas metas caso alguns de seus membros não es- 
tiverem suficientemente capacitados. A gestão deve contribuir para o desenvolvi- 
mento das competências das pessoas. 

Mais adiante nesse capítulo trataremos de várias práticas úteis que podem ser 
utilizadas pelo time, com apoio da Gestão para fomentar o aprendizado e capacitação 
das pessoas. 


Estruturar 


Muitos times trabalham dentro de um contexto organizacional complexo, por- 
tanto é importante considerar estruturas que promovam a comunicação. Como di- 
vidir as pessoas em equipes? Unir as pessoas de acordo com suas funções ou formar 
equipes que entreguem o produto do início ao fim? Como essas equipes poderão se 
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comunicar, diretamente ou por intermédio de alguém? Qual a quantidade ideal de 
membros em um time ágil? Todas essas são questões relevantes em se tratando de 
estruturar a organização. 

Mais adiante, falaremos de formações de equipes, e abordaremos esse assunto 
com mais profundidade. 


Melhorar tudo 


O importante é não parar de questionar. 
— Albert Einstein 


Enquanto muitos de nós passa a vida reclamando que as coisas não são da forma 
como gostaríamos que fossem (que os políticos são corruptos, que a empresa é chata, 
que o mercado está dominado por mercenários, ou seja lá o que for que não está 
bem), Mahatma Gandhi foi um verdadeiro exemplo deixando-nos essa filosofia: 
“Seja a mudança que você quer ver no mundo”. 

Agilidade tem a ver com Melhoria Contínua. E nada melhora se permanecer 
como está. As coisas melhoram quando mudam. Então, para melhorar, pessoas, 
times, e organizações precisam melhorar continuamente para evitar falhas e evoluir 
sempre. 


A Gestão 3.0 traz uma abordagem sistêmica para Gestão 3.0 que consiste em [10]: 


1) Considerar o sistema: Uma rede social é complexa e adaptativa. Ela vai se adaptar 
às suas ações, e você também deve se adaptar à rede social. É como dançar com 
o sistema. 


2) Considerar os indivíduos: Saiba que as pessoas são a parte crucial do sistema 
social, e que elas são diferentes umas das outras. Não há uma abordagem única 
que sirva para todos. Simplesmente pedir para que as pessoas mudem, raramente, 
é suficiente. A diversidade é o que faz sistemas complexos funcionarem, e é por 
isso que trabalhar com uma diversidade de métodos é crucial para lidar com as 


pessoas. 


3) Considerar as interações: Um comportamento se espalha através de um sistema 
complexo. Em uma rede social, tudo gira em torno de indivíduos e das interações 
entre eles. Comportamentos se espalham de forma viral, e estimular a rede social 
pode ajudar a vencer a resistência às mudanças e a transformar uma organização 
por completo. 
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4) Considerar o ambiente: As pessoas sempre se organizam dentro do contexto de 
um ambiente. O ambiente determina como o sistema pode se auto-organizar, e 
você deve ser capaz de ajustar o ambiente. Isso porque o comportamento das 
pessoas depende do ambiente, e se você mudar o ambiente, você também muda 
as pessoas. 


No livro Como Mudar o Mundo: Gestão de Mudanças 3.0, Jurgen Appelo, des- 
creve em detalhes como você pode aplicar cada uma dessas abordagens para se tornar 
um agente de mudanças bem sucedido. 


6.2 FEEDBACK 


Não é à toa que um dos valores de XP é Feedback [13]. A constante mudança do 
mundo à nossa volta cria a necessidade de darmos e receber feedback com frequên- 
cia. 

Desenvolvedores precisam receber feedback sobre as alterações que fizeram no 
software, precisam receber feedback a cada alteração para que saibam se os testes de 
regressão continuam passando, por isso utilizam integração contínua e TDD. Além 
disso, precisam saber se o código que escrevem está legível do ponto de vista de seus 
pares. O Product Owner precisa de feedback dos usuários, o time precisa de feedback 
da gestão, e a gestão de feedback do time. Os ciclos de feedback são importantes 
e necessários em diversas atividades e relacionamentos existentes no processo de 
desenvolvimento. 

Quanto mais rápido e frequente for o feedback, mais rápido pode-se responder, 
corrigir e melhorar. Existem algumas práticas e ferramentas que podem ajudar as 
pessoas a dar e receber feedback. A seguir, estudaremos algumas delas. 


Reuniões One-on-ones: conhecendo o time 


Para liderar pessoas, é preciso conhecê-las bem. Cada pessoa é única e possuir 
diferentes desejos, pontos fortes e fracos. Um bom gestor precisará saber quem são 
as pessoas (seus pontos fortes, fracos e interesses) e em que estão trabalhando, qual 
a missão da equipe e de que forma ela agrega valor e como as equipes se encaixam 
na organização como um todo. 

As reuniões one-on-ones basicamente são oportunidades em que o gestor se 
reúne com cada membro da equipe, um a um para conversar, e perguntar coisas 


como: 
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e Como as coisas estão? 

e Como seu projeto esta indo? 

e O que você mais gosta no seu trabalho? 
e Quais são os aspectos mais frustrantes? 


e Você poderia me falar mais a respeito de ...? 


Reuniões One-on-ones, realizadas da forma correta, constroem bons relaciona- 
mentos. Gestores que fazem essas reuniões com frequência muitas vezes as consi- 
deram um dos melhores usos de seu tempo e uma ferramenta primordial. As one- 
on-ones podem ajudar sua equipe a saber o que você espera deles, além de criar um 
canal para coaching, desenvolvimento de carreira, confiança, feedback e oportuni- 
dade para reportar o status do trabalho. 

Tothman e Derby recomendam que os gerentes façam reuniões one-on-ones se- 
manalmente. Na Bluesoft nós as fazemos a cada três meses, e sem dúvidas, podemos 
dizer que elas trazem bons resultados. 





DICAS PARA REUNIÕES ONE-ON-ONES 


e Ritmo: Encontre as pessoas no mesmo dia e por volta do mesmo 


horário, isso cria ritmo e faz com que as pessoas venham prepara- 


das. 


e Presença: não permita que a reunião seja interrompida por liga- 
ções, e-mails etc. 


e Compromisso: cancelar ou desmarcar por qualquer razão de- 


monstra que você não se importa. 


e Consistência: Procure manter um formato semelhante em diferen- 


tes encontros. 


e Adaptabilidade: Adapte a frequência, formato ao momento e cir- 
cunstancias do time. 
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Não se engane com a ideia de que o gestor não deveria passar tanto tempo com as 
pessoas para não perder o foco da gestão, porque isso faz parte da gestão. Aprender 
sobre as pessoas faz parte. Saber em que elas são boas e quais são seus pontos a 
melhorar é importante. Aprender sobre seus desejos e aspirações também faz parte. 


Feedback 360 


Feedback é essencial para o amadurecimento e evolução das pessoas. Precisamos 
saber se estamos indo bem, e em que precisamos melhorar. 

Imagine se você pudesse receber feedback de diversos pontos de vista de dife- 
rentes pessoas para saber exatamente em que você pode melhorar. É possível! Há 
uma ferramenta conhecida como Feedback 360 graus. 

O feedback pode ser contextualizado em competências que o time julgar ne- 
cessárias para que possam atingir suas metas, entregar resultados de qualidade, e 
atender as expectativas dos clientes, e manter um bom relacionamento e ambiente 
de trabalho. Pode se avaliar tanto competências como comunicação, colaboração, 
como coisas mas específicas como conhecimentos em tecnologias, ou boas práticas 
de desenvolvimento. 

Como toda ferramenta, pode ser bem ou mal utilizada. Infelizmente, alguns ge- 
rentes a utilizam para realizar avaliações tradicionais no estilo de cima para baixo 
[8] em que apenas gerentes avaliam subordinados e subordinados avaliam gerentes. 
É importante evitar fazer uma relação direta do resultado do feedbacks, com pro- 
moções, demissões, punições, bônus etc. para não perder a confiança das pessoas e 
criar um clima de tensão na equipe. 

É importante preparar as pessoas, e explicar o objetivo do feedback, para que não 
se torne uma sessão de “fogo para todo lado” em que críticas destrutivas são trocadas 
pelos membros da equipe resultando apenas em egos feridos. 

A essência do feedback 360 graus, de um ponto de vista ágil, é que você possa 
dar feedback para todos os membros do seu time, receber feedback de todos e, em 
alguns casos, inclusive, se autoavaliar com objetivo de que todos possam utilizar esse 
feedback para melhorar. Já a forma pode variar bastante. Há diversas abordagens 
que podem ser usadas, por exemplo, pode ser anônimo, pode ser face a face, pode 
ser mais subjetivo e aberto, ou mais objetivo e relacionado a metas específicas, o 
resultado pode ser particular, ou pode ser publicado para todos. Alguns dos formatos 
mais comuns são: 

1. Face a face: Uma reunião informal em um ambiente casual, em que cada parti- 
cipante oferece e recebe feedback de cada um dos outros [8]. De acordo com Jurgen 


128 


Casa do Código Capítulo 6. Otimizando o Sistema 





Appelo, reuniões informais funcionam melhor do que avaliações mais tradicionais 
porque as pessoas podem discutir abertamente e esclarecer dúvidas para entender 
melhor pedindo exemplos reais. 

2. Envelopes: Essa é uma forma que geralmente é um pouco aberta, em que 
todos os membros do time, recebem um envelope com seus nomes escritos, contento 
folhas em branco. A equipe, então, senta em formato de círculo, e os envelopes são 
passados em sentido horário de forma, que cada um dos membros do time, ao pegar 
o envelope do colega escreve algo positivo sobre ele e algo que ele pode melhorar. 
Ao final, os envelopes voltam a mão de seus donos com as folhas preenchidas com o 
feeback. Cada um fica com seus resultados para analisar o que pode melhorar. 

3. Formulários: A forma mais tradicional é através de formulários (que podem 
ser digitais ou em papel) em que cada membro do time avalia objetivamente cada 
uma das competências de todos os seus colegas, através de uma nota, que pode ser de 
1a 10, por exemplo. Depois de todos terem avaliado, os resultados são consolidados 
e cada um recebe seus resultados, assim como sua avaliação em relação a média do 
time, e sua própria autoavaliação. 

Defina um timebox para o feeback, para evitar que a sessão se torne cansativa e 
interminável. 

Você pode tentar diversos formatos até que encontre um que funcione melhor 
em sua equipe, ou variar o formato a cada nova sessão de feedback. O mais im- 
portante é ter em mente que o objetivo é fomentar o feedback para que as pessoas 
melhorem. 


6.3 ESCALANDO ÁGIL COM PROGRAMAS E PORTFOLIOS 


E quando uma equipe ágil não for suficiente? E quando a organização tiver vários 
produtos ou produtos grandes demais para uma única equipe ágil? Como escalar a 
agilidade? Como determinar quem trabalha no quê? Essas são perguntas comuns 
que nos fazemos ao nos deparar com situações em que precisamos de diversas equi- 
pes para atingir os objetivos da organização. 

Desenvolvimento de sistemas de larga escala podem ser realizados através de di- 
versos times trabalhando paralelamente em um mesmo ciclo de releases, geralmente 
com data e qualidade fixos, porém, com escopo variável [37]. Esse nível de desen- 
volvimento em que há várias equipes trabalhando com um objetivo final comum é 
o nível de Programa. 


Em um cenário como esses, é comum que alguém desempenhe o papel Product 
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Manager, ou que haja uma comunidade de prática de Product Owners para coorde- 
nar, alinhar e lidar com esses requisitos de mais alto nível, que são organizados e 
priorizados em um Program Backlog. 

Para organizar muitos programas, trabalha-se com portfólios, onde se trata dos 
requisitos de mais alto nível, os épicos. Nesse nível é realizada a gestão de todos os 
investimentos da organização que serão realizados através de programas e projetos. 

Assim teremos uma hierarquia formada por Portifólios, Programas e Projetos, 
em que cada projeto será desenvolvido por uma pequena equipe ágil. 


6.4 FORMAÇÃO DAS EQUIPES 


Uma premissa importante do desenvolvimento ágil são as equipes cross-funcionais, 
ou seja equipes que possuem pessoas com todas as habilidades necessárias para en- 
tregar as histórias de usuário do início ao fim. Elas são geralmente chamadas de 
equipes de feature teams ou funcionalidades. 

É diferente das equipes funcionais que, geralmente, eram formadas nos proces- 
sos tradicionais, com base na função, por exemplo, equipe de programadores, equi- 
pes de analistas, equipes de testadores etc. Em organizações que utilizam esses pro- 
cessos tradicionais geralmente o trabalho passa de uma equipe para a outra até que 
fique pronto, resultando, muitas vezes, em burocracia e problemas de comunicação. 
A figura 6.3 ilustra a diferença na formação de equipes funcionais e cross-funcionais: 
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Figura 6.3: Equipes Funcionais e Cross-Funcionais 


Nas equipes cross-funcionais todos são responsáveis pelo resultado da entrega, 
e não apenas por sua área de especialização. Além disso, é comum que os especia- 
listas ensinem os outros um pouco sobre sua área de conhecimento de modo que, 
com o tempo, todos podem ajudar no que mais for necessário, alavancando assim a 
produtividade do time [56]. 

Isso não significa que todos têm que saber fazer todo o trabalho, e que têm que 
fazer todo o trabalho muito bem. Na verdade, equipes ágeis incentivam a formação 
de especialistas generalistas, são pessoas que fazem um tipo de trabalho extrema- 
mente bem — desenvolver, por exemplo —, porém também são capazes de fazer 
outros tipo de trabalho — documentar ou testar, por exemplo. Equipes formadas 
com profissionais assim tendem a eliminar desperdícios e gargalos na organização 
[8]. 

Esses profissionais sao conhecidos como Profissionais T, porque sao especiali- 
zados em alguma área de conhecimento, representada pela pela “perna” da letra T, 
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porém são capazes de fazer coisas em outras áreas de conhecimento representado 
pela amplitude da “cabeça” da letra T, veja um exemplo na figura 6.4: 
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Figura 6.4: Profissional T 


Equipes cross-funcionais nem sempre são feature teams , em vez disso, 
podem ser component teams. A diferença desses tipos de equipe é que em vez 
de construir o software de ponta a ponta e entregá-lo pronto para que o cliente final 
possa utilizar, essas equipes ( component teams) constroem partes da aplicação, 
ou componentes, que, geralmente, são entregues para que outra equipe possa utilizar 
e enfim agregar a funcionalidade que precisa para ser entregue ao cliente. 

Por exemplo, o time A pode estar trabalhando em um componente visual 
de front-end, enquanto o time B está preparando o backend da aplicação. Em- 
bora seja recomendável trabalhar com feature teams , Mike Cohn alerta 
que em certas situações e contextos pode ser interessante se 
utilizar de component teams. 

Equipes ágeis são capazes de entregar software funcionando a cada iteração por- 
que são formadas de especialistas generalistas capazes de juntos construir funciona- 
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lidades de ponta a ponta. 

Outra diferença notável é o tamanho das equipes, em processos tradicionais era 
comum encontrar equipes funcionais com mais de 30 pessoas, muitas vezes che- 
gando em extremos de mais de 100. As opiniões quanto a tamanho ideal de uma 
equipe ágil podem variar, mas, geralmente são equipes pequenas que variam de 5 a 
12 integrantes. Quanto mais pessoas envolvidas mais frágil se torna a comunicação 
do time, mais coordenação se torna necessária, e, geralmente, menor é a produtivi- 
dade [66]. 

É importante levar em consideração, como discutimos no capítulo 5 que as pes- 
soas precisam trabalhar juntas por um tempo para que sejam uma equipe de verdade, 
e não apenas um grupo de trabalho. Por isso, é importante que elas possam perma- 
necer por algum tempo na mesma equipe, embora, de tempos em tempos, pequenas 
mudanças, rotacionando membros de um equipe para a outra, podem ser positivas 
para disseminar o conhecimento dentre as equipes. 





CONTRATAÇÃO COLABORATIVA 


Algo que sem dúvida, influencia na formação de equipes, são os novos 
membros que são contratados ao longo do tempo. A contratação colabo- 
rativa é uma prática que basicamente consiste em permitir que as pessoas 
da equipe da qual possivelmente o candidato fará parte possa participar 
do processo de contratação, fazendo perguntas e criando desafios para o 
candidato. 

É claro que essa prática, requer confiança da gestão e maturidade da 
equipe, mas, dessa forma, além de o time colaborar para selecionar pes- 
soas mais aderentes à cultura e às necessidades da organização, as equi- 
pes tendem a aceitar melhor o novo membro, dado que participaram 
ativamente do processo de contratação e seleção, e concordarão que o 
novo membro tem as características que consideram importantes para a 


equipe. 











6.5 PRÁTICAS DE APRENDIZAGEM 


“Sejamos claros: Sua carreira é sua responsabilidade, seu empregador não é sua Mãe” 
— Robert C. Martin 


133 


6.5. Práticas de Aprendizagem Casa do Código 





Há um antigo ditado que diz que “como na natureza, ou você está verde e cres- 
cendo ou maduro e apodrecendo”. Na área de tecnologia da informação a taxa de 
mudança e inovação é muito alta, e nós profissionais não podemos parar de apren- 
der. 

Jurgen Appelo, afirma que a educação dos colaboradores não é a principal ativi- 
dade da organização. Por outro lado, esperar que as pessoas se desenvolvam sozinhas 
nem sempre é uma abordagem bem-sucedida: “Eu acredito que a maioria das pes- 
soas quer aprender porém não sabe como, ou acabam focando em coisas irrelevantes. 
Defina restrições no ambiente para que as pessoas aprendam coisas relevantes” [11] 

Alguns profissionais, infelizmente, não se responsabilizam por seu próprio de- 
senvolvimento profissional, e como em organizações também não há incentivo, esses 
acabam ficando improdutivos e desatualizados com o tempo. 

Em seu livro Clean Code, Robert Martin enfatiza a importância de que todos 
os profissionais se responsabilizem por suas carreiras [42], algumas organizações in- 
centivam o aprendizado e criam um ambiente repleto de recursos para que as pessoas 
naturalmente estejam sempre aprendendo algo novo. Isso é fantástico, mas, se sua 
organização não der espaço para atividades de aprendizagem, não desanime por isso, 
afinal a responsabilidade ainda é sua. 

Nesse tópico abordaremos algumas práticas que você e seu time podem utilizar 
para estimular o aprendizado de todos. 


O ambiente faz diferença 


A equação de Lewin, desenvolvida pelo psicologo Kurt Lewin, defende que o 
comportamento de uma pessoa é uma função de sua personalidade e de seu ambiente 
[45]. Isso significa que ao mudar o ambiente você pode mudar o comportamento de 
alguém. 

Para ilustrar, imagine que você é um desenvolvedor que acabou de ser contratado 
por uma nova empresa. Em seu primeiro dia de trabalho, notou que todos os seus 
colegas têm o hábito de ler e estudar bastante, há livros por toda a parte espalhados 
nas mesas das pessoas, ao ouvir uma conversa sobre tecnologia no café você por um 
momento pensou que as pessoas estavam falando em grego: Scala, Big Data, Clojure, 
Crystal, Dataware house, Business Intelligence, Hadoop, Kernel... Na verdade, era 
apenas uma conversa normal sobre tecnologia com uma série de palavras-chave que 
você nunca tinha ouvido falar antes. 

Em um ambiente como esse, há uma grande probabilidade de que você chegará 
em casa e, naturalmente, começará a estudar e buscar equiparação com seus colegas 
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e, para acompanhá-los, criará o hábito de manter-se sempre atualizado. 

Agora, pense num cenário diferente, em que ao chegar em seu primeiro dia de 
trabalho, você percebe que as pessoas são bem acomodadas, que a tecnologia que a 
empresa está atualmente utilizando já está ultrapassada há muito tempo e que nin- 
guém parece se importar em estudar ou buscar novas abordagens. Você terá a mesma 
motivação de estudar ao chegar em casa? Provavelmente não. 

O que ocorre que é nós temos uma grande tendência de nos conformarmos ao 
ambiente em que estamos inseridos. 

É por isso que um ambiente que facilita e promove o aprendizado é muito impor- 
tante para fomentar equipes tecnicamente excelentes. A seguir você será apresentado 
a algumas práticas para ajudá-lo a criar um ambiente que facilita a aprendizagem. 


Comprometa-se com sua carreira 


Muitos de nós acredita que ao terminar a faculdade está formado mas, na ver- 
dade, especialmente em uma área tão volátil quanto a área de tecnologia da infor- 
mação, essa formação deve durar a vida inteira para que você continue sendo um 
profissional eficiente e relevante para o mercado de trabalho. 

Quando está na faculdade, você dedica em média 4 horas do seu dia para sua 
formação, para estudar. Depois que acaba a faculdade, muitos, infelizmente, passam 
a dedicar zero horas. É importante que você tenha um compromisso consigo mesmo 
de manter-se em constante estado de aprendizagem e para isso você precisará dedicar 
algumas horas na sua semana. Não pode dedicar 4 horas como fazia na época na 
faculdade? Não tem problema. Que você dedique 20 minutos por dia então. Mas 
faça e verá que isso fará grande diferença na sua carreira. 


O Básico 


Inglês: Nos tempos globalizados em que vivemos saber falar apenas sua língua 
nativa já não é mais suficiente. Grande parte do material disponível para aprendizado 
está em inglês, e o tempo de tradução para o português é, muitas vezes, longo demais. 
Estude inglês de forma a poder ler documentação de projetos open-source, tutoriais, 
artigos, e assistir a palestras e apresentações. 

Leitura: Crie o hábito de ler. Não apenas livros, mas também blogs e portais de 
tecnologia (como o InfoQ.com, por exemplo). Fique ligado no que está mudando e 
nas novas tecnologias que estão surgindo a todo momento. 


Esteja sempre lendo um livro. Quando terminar de ler este livro, não espere. 
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Comece a ler um próximo e não pare nunca. Eu, particularmente, mantenho um 
Backlog de livros no GoodReads.com, há centenas de livros que quero ler e man- 
tenho uma lista priorizada lá, sempre sei qual o próximo livro que começarei a ler 
assim que acabar o atual. 

Cuidado porém, para não cair no hábito de comprar mais livros do que pode 
ler, falo por experiência própria. Em certa altura da minha vida, percebi que, mais 
ainda do que ler, eu gostava de comprar livros. Mantenha sua lista de livros, e vá 
comprando à medida que for terminando de ler o livros que já tem. 

Eventos e Mídia: Participe de eventos e conferências sobre tecnologias e assun- 
tos do seu interesse, troque informações com outros profissionais e construa uma 
rede de relacionamentos. Hoje em dia, temos uma grande riqueza de material em 
áudio e vídeo disponíveis online (Screencasts, Podcasts, Vídeos), além disso, muitas 
conferências gravam suas palestras e disponibilizam online para a comunidade. Use 
tudo isso a seu favor. 


Coding Dojo 


Coding Dojo é uma reunião de desenvolvedores com o objetivo de trabalhar em 
um desafio de programação. Eles se divertem e se engajam para trabalhar na solução 
do problema ao passo que desenvolvem suas habilidades [2]. 

A premissa básica é que o aprendizado de habilidades de codificação é um pro- 
cesso contínuo que desenvolvedores devem se dar a oportunidade de codificar com 
o objetivo de treinar. Não importa qual o nível técnico dos desenvolvedores, todos 
participam e aprendem juntos. 

A primeira ideia de sessões de prática de programação individuais e fora do horá- 
rio de trabalho foi proposta por Dave Thomas [62] posteriormente Laurent Bossavit, 
propôs Coding Dojos, com mesmo objetivo, porém com a participação de um grupo 
de programadores [14]. 

O ambiente de um coding dojo estimula o aprendizado colaboração, diversão, e é 
propício para se tentar aplicar novas ideias e boas práticas de programação, como De- 
senvolvimento Guiado por Testes (TDD), Refatoração, e Programação em par, por 
exemplo. Além disso, desenvolvedores aprendem muito ao ver as diferentes pers- 
pectivas e abordagens de outros desenvolvedores. 

Tudo que é preciso para realizar um coding dojo é um computador, um teclado, 
um projetor, um desafio de programação para ser resolvido e desenvolvedores inte- 
ressados em participar. 
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Existem diferentes formatos de Coding Dojos, o Randori Kata e o Prepared 
Kata. 

No formato Randori, os programadores trabalham juntos na solução do desafio 
de programação [14], seguindo o seguinte processo: 


1) Escolher um desafio de programação: Dica, uma simples busca no Google por 
“source of problems for coding dojos” trará algumas ideias interessantes como: 
transformar números romanos em arábicos, escrever números por extenso etc. 


2) Um par de desenvolvedores vai até o computador e trabalhar em par no problema, 
a cada X minutos (geralmente, 7 minutos) o navegador, assume o papel de con- 
dutor dando lugar para que a alguém da audiência assuma o papel de navegador, 
e o condutor anterior volta a plateia, o novo par dá continuidade de onde o par 
anterior estava. O processo se repete de X em X minutos, até o final do time- 
box. Os desenvolvedores aplicam desenvolvimento guiado por testes, e enquanto 
a barra estiver verde, indicando que os testes estão passando, todos da plateia 
podem dar sugestões ou discutir abordagens, mas quando a barra estiver verme- 
lha (indicando que os testes estão quebrando) apenas o navegador e o condutor 
podem falar. 


3) Uma rápida retrospectiva para que os participantes apontem o que correu bem e 
o que pode ser melhorado no próximo coding dojo. 


Já no formato Prepared Kata alguém que já resolveu um desafio de programação 
anteriormente apresenta a solução de um problema passo a passo desde o ponto zero, 
utilizando desenvolvimento guiado por testes. Cada passo deve fazer sentido para 
todos os participantes (audiência), de forma que as pessoas podem interromper a 
qualquer momento em caso de dúvidas [2]. 

Dojos são uma excelente ferramenta de aprendizado para desenvolvedores, e 
organizações podem ceder tempo e/ou espaço para que desenvolvedores possam 
realizá-los com o intuito de praticar suas habilidades e se tornarem melhores pro- 
fissionais. 


Clubes de Discussão de Livros 


Um Clube do Livro é um grupo de pessoas leem o mesmo o livro e se reúnem com 
determinada frequência para discutir capítulos ou trechos do livro, expressando suas 
opiniões, aprendizados, coisas que gostaram e não gostaram a respeito dos conceitos 
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e ideias apresentadas do livro. Geralmente, as pessoas vão lendo o livro à medida 
que os encontros acontecem. São comum, por exemplo, reuniões semanais, em que, 
antes de cada reunião lê-se um dos capítulos para discussão. 

Numa organização em transição para métodos ágeis, por exemplo, pode ser uma 
excelente ideia formar um clube do livro, e escolher um livro sobre métodos ágeis 
para envolver toda a equipe no aprendizado que sem dúvida será muito útil na tran- 
sição. 


Brown Bag Sessions 


“Brown Bag Sessions” são reuniões durante a pausa para o almoço em que as 
pessoas fazem apresentações e compartilham informações. Nos Estados Unidos é 
comum que as pessoas levem seus lanches para o almoço em sacos de papel pardos 
(brown bags), como aqueles que as padarias costumam utilizar para pães aqui no 
Brasil, daí o nome “Brown Bag Sessions”. 

Durante essas reuniões, geralmente, as pessoas comem enquanto assistem a uma 
apresentação preparada por um dos membros do time. É uma forma fácil e rápida 
de se criar uma oportunidade para aprendizado, uma vez que é um horário que na 
maioria das vezes mais pessoas poderão participar do que antes ou depois do horário 
de trabalho. 

Se você gostaria que sua organização, investisse em um tempo durante o horário 
de trabalho para esse tipo de atividade de aprendizado, “Brown Bag Sessions” podem 
ser uma ótima forma de se começar, porque não afeta o tempo de trabalho da equipe. 
Ao passo que as pessoas participam das reuniões e os resultados se mostram promis- 
sores, o apoio da gestão para realização dessas atividades poderá ser mais facilmente 
conquistado. 


6.6 HACKATHONS 


Um Hackathon é um dia de trabalho com foco no aprendizado e autodesenvolvi- 
mento através de experimentos e testes de novas ideias. 

Uma empresa australiana chamada Atlassian possui um evento realizado a cada 
três meses chamado ShipIt Days. Nesse dia todas as pessoas da empresa podem 
escolher uma de suas ideias para trabalhar, de modo que, ao final de 24 horas, todas 
devem entregar alguma coisa pronta. Outras empresas como a Facebook e Spotify 
adotaram abordagens semelhantes [11], e atualmente, essa tem sido uma prática de 
inovação e aprendizado organizacional muito utilizada em startups e organizações 
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inovadoras. 

Os projetos podem ser feitos individualmente, ou podem ser colaborativos. É 
comum que no início do Hackathon haja um tempo em que todos se reúnem para 
apresentar suas ideias e então equipes sejam formadas de maneira auto-organizada. 

Muitos desses projetos acabam se tornando produtos reais das empresas que re- 
alizam Hackathons. É comum que alguma equipe tenha ideias para os produtos que 
desenvolvem porém, por alguma razão, não estão no backlog, ou têm baixa priori- 
dade. Essa é uma oportunidade de tentar colocar a ideia em prática e apresentar o 
resultado ao Product Owner e ao time. Talvez, a ideia nunca faça parte do produto, 
de fato, talvez torne-se uma funcionalidade importante do produto; o que interessa 
é que o aprendizado trazido da experiência poderá ser, por si só, muito recompen- 
sador. 

Hackathons são oportunidades para que as pessoas possam aprender, experi- 
mentar e inovar. São eventos motivadores que permitem que a equipe quebre a ro- 
tina e experimente coisas que em um contexto normal talvez fossem arriscadas ou 


teriam baixa prioridade. 


6.7 COMUNIDADES DE PRÁTICA 


Organizações precisam harmonizar práticas, processos, e ferramentas e diversos ti- 
mes e departamentos, além disso as pessoas precisam compartilhar conhecimento e 
desenvolverem-se além dos limites das organizações [9]. Para esse objetivo cultivar 
comunidades de prática pode ser de grande ajuda. 

Equipes ágeis, geralmente, são cross-funcionais, ou seja, profissionais com pa- 
péis e interesses semelhantes estão distribuídos entre diversos times. Nesse cenário, 
formar comunidades de práticas para criar oportunidades de compartilhamento e 
aprendizado para esses profissionais pode alavancar consideravelmente o desenvol- 
vimento das pessoas. 

Imagine uma organização com 10 times de Scrum, cada time possui um Scrum 
Master, e pelo menos dois testadores, alguns designers e alguns desenvolvedores. A 
criação de comunidades de prática nessa organização permitiria que em momentos 
oportunos todos os Scrum Masters se reunissem para tratar de assuntos relevantes 
para todos eles, assim como todos os testadores, todos os designers e todos os de- 
senvolvedores. Veja na figura 6.5 um exemplo: 
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Figura 6.5: Comunidade de Prática 


Comunidades de prática são grupos de profissionais que compartilham interes- 
ses comuns ou uma área comum de trabalho. Podem ser formadas ao redor de temas, 
papéis na organização, tecnologias etc. Os participantes aprendem e compartilham 
informações relevantes, ideias, e boas práticas, e padronizam métodos de trabalho. 

A maneira com a qual as organizações lidam com as comunidades de prática 
pode variar bastante, algumas podem possuir comunidades de práticas informais 
que não são reconhecidas nem apoiadas pelo organização, outras podem ser reco- 
nhecidas e apoiadas [20] e que podem inclusive possuir responsabilidades, e mui- 
tas vezes até ter um tempo reservado durante o horário de trabalho para reuniões 
e discussões. Isso depende do valor que a comunidade de prática pode agregar à 
organização e da capacidade da gestão de enxergar e apoiar essas iniciativas. 
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6.8 E AGORA, O QUE EU FAÇO AMANHÃ? 


Faça um exercício com a sua equipe, crie uma lista com dez problemas que vocês 
tenham enfrentado na última semana de trabalho, e então para cada um deles ve- 
rifique como foram resolvidos. Será que vocês realmente foram em busca da causa 
do problema e o resolveram de uma vez por todas ou simplesmente aplicaram um 
paliativo para aliviar os sintomas do problema temporariamente? 

Que tal marcar uma primeira rodada de one-on-ones? 

Procure um assunto de interesse de sua equipe, e proponha a formação de um 
Clube do Livro para fomentar a discussão e aprendizado. 

Marque um primeiro coding dojo com seu time. 

Faça uma apresentação sobre esse capítulo, e marque uma “Brown Bag Sessions” 
para apresentar o que você tem aprendido. 

Converse com sua equipe sobre ideias de projetos, melhorias que sempre quise- 
ram ver nos produtos da sua organização, ou experimentos que gostariam de fazer. 
Que tal propor um Hackathon para criar uma oportunidade de colocar essas ideias 
em prática? 

Existe algum assunto, tecnologia, prática que lhe interessa no contexto da sua 
organização. Você acha que outras pessoas também poderiam estar interessadas em 
discutir e evoluir esse tema na sua organização? Que tal formar uma comunidade 
prática em cima disso? 

Proponha à gestão da sua organização a criação de um quadro de autoridade 
para deixar a autonomia do seu time transparente dentre as diversas áreas de decisão- 


chave do seu projeto. 
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E Agora? 


Agora, além de conhecer um pouco mais sobre métodos ágeis você já tem um boa 
ideia de muitas práticas e técnicas interessantes, as quais pode aplicar no seu dia-a- 
dia. 

O aprendizado não acaba nunca, e utilizar um método ágil é só o começo. Cada 
time, cada organização, cada projeto é diferente, e será uma experiência única e um 
desafio único. 

Muito do que conheceu nesse livro poderá te ajudar a descobrir formas melhores 
de enfrentar esses desafios e de buscar ideias para otimizar o seu processo para cada 
um dos cenários que encontrar. 

Procure dar mais importância sempre para os princípios e valores ágeis do que 
para as práticas em si, as práticas poderão (e deverão) mudar, mas os valores, devem 
permanecer. 

Para que possamos discutir sobre métodos ágeis, existe um grupo de discussões 
no Google Groups, lá você poderá interagir comigo e com outros leitores do livro. 
Acesse em https://groups.google.com/d/forum/livro- agile 
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Fique à vontade para entrar em contato comigo nas redes sociais. Para acessar 
os links de todas as redes sociais que participo acesse http://contato.andrefaria.com. 

Aproveito também para convidá-lo a ler os artigos que escrevo em http://blog. 
andrefaria.com. 

Por fim, mais uma vez, agradeço à você. 

Obrigado! 
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Apéndice A: Ferramentas de Apoio 


E essencial para equipes distribuidas, ou equipes que possuem membros que traba- 
lham em regime de home-office (trabalhar remotamente de casa), possuir um soft- 
ware que os ajude a manter a visualização do fluxo de trabalho, e mesmo para times 
que trabalhem colocados, um software pode ser de grande ajuda, embora não seja 
essencial. 

Uma das principais vantagens de se utilizar um software como apoio, são as fun- 
cionalidades que permitem armazenar detalhes extras das histórias de usuário, visu- 
alização de métricas como tempo de ciclo e lead time, geração de gráficos de burn- 
down e burnup, entre outros facilitadores. 

Alguns softwares que podem ajudar sua equipe são: Acelerato (em português), 
Lean Kit Kanban, Agile Zen, Target Process, Silver Catalyst, RadTrack, Kanbanery, 
VersionOne, Greenhopper (com Jira), Flow.io, entre outros. 

Se houver um quadro físico e um virtual, é importante garantir que ambos per- 
maneçam atualizados e consistentes. Por isso existe o papel do “Sticky Buddy” (su- 
gerido por Darren Davis), que nada mais é do que alguém que assume a respon- 
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sabilidade de manter o quadro físico sempre atualizado em caso de alguém estar 
trabalhando remotamente e não poder mover os itens do quadro físico. 


Se você e sua equipe nunca utilizaram um software como esses antes, vale a pena 
propor um teste para analisar se agrega ou não valor à vocês. 
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